Zero bug : la méthode Toyota !

0:10 Alors bonjour à tous, bienvenue dans ce workshop. Aujourd'hui on va parler de Zero Bug et en particulier on va faire le parallèle entre le monde de l'industrie et le monde informatique. Le monde de l'industrie, quand Toyota a commencé à produire des voitures, ils ont quand même beaucoup d'expérience, ils ont fait beaucoup de recherches sur les méthodes, et à tel point que quand eux comptent les défauts sur les pièces, ça se compte en parties par millions. C'est-à-dire que quand on fait un million de boulons, on va en trouver un ou deux qui va avoir un défaut. Et donc c'est vraiment ce qu'on cherche à atteindre nous dans notre industrie informatique. C'est, on espère un jour compter les bugs en millions de user stories développés ou en millions de lignes de code. Voilà. Alors, zéro bug, c'est un bien grand mot, parce que si vous étiez au talk précédent de Thomas et Aurore, il faut...

1:13 Il se disait que ce n'était pas une fin en soi. C'est quelque chose qu'on essaye d'atteindre, c'est asymptotique, mais il faut rester zen vis-à-vis de ça. Ce n'est pas forcément l'objectif. En fait, Zero Bug, on le choisit parce qu'on pense que c'est vraiment la meilleure stratégie pour que les... équipes apprennent. C'est-à-dire que le Lean et Toyota a compris qu'en fait l'entreprise c'est une somme de personnes et que plus les personnes sont fortes individuellement, plus l'entreprise va être forte dans son ensemble. Évidemment il y a la collaboration qui joue, mais la base c'est quand même que chaque personne développe une expertise vraiment technique poussée, et que c'est cette expertise-là qui va contribuer à la réussite de l'entreprise. Voilà. Je n'ai pas appuyé sur le bouton. Je te laisse prendre la suite. Ah oui. Ça y est, on l'a noté. La user excellence de la maniette. On se présente rapidement. Je m'appelle Woody, je suis le CTO et cofondateur de Sipios.

2:16 Sipios et Reynald à Theodo, on est dans un Group de sociétés de services, qui s'appelle le Group Theodo. Sipios, on est spécialisé sur les services financiers et la FinTech. Et donc je suis comme toi Reynald, passionné de Lean. On visite des usines, le mois dernier une usine qui fabrique des réfrigérateurs qui font du Lean. Et on essaie de comprendre comment ça marche dans la tech. J'ai d'autres passions plus tech en soi, les API, l'open finance, comment on peut... Faire une finance qui est invisible grâce à la tech. Et donc on va vous parler plutôt de l'aspect Lean aujourd'hui. Voilà, et moi aussi j'adore les flux, les usines, et je m'occupe de l'ingénierie à Théodo, donc les sujets de software quality. et ensuite de leadership pour la conduite du changement, qui est extrêmement importante. Comme c'est un workshop, on va aller très vite sur la théorie pour essayer de rentrer dans un exemple concret juste après. Qui sera du coup, on va essayer de le rendre interactif, la partie pratique. Et donc quand même quelques éléments de théorie sur ce que fait Toyota.

3:21 Donc on a eu pas mal de scale sur certains projets chez Theodo, et à un moment les bugs ont commencé à vraiment augmenter, et je suis tombé sur ce bouquin de ce monsieur qui s'appelle Sadao Nomura. Qui donc écrit un bouquin qui parle de qualité chez Toyota. Et ce qui est assez intéressant, c'est qu'il commence le bouquin en expliquant que c'est un peu l'extrême programming pour l'industrie. Pour une fois que c'est fait dans ce sens-là, j'ai trouvé ça assez marrant. Et donc c'est quelqu'un qui était envoyé en fait par Toyota dans les usines de Toyota qui produisaient suffisamment de défauts pour que Toyota n'accepte même pas qu'ils exportent des bagnoles. Notamment c'est lui qui avait été envoyé en Afrique du Sud, dans une usine juste post-apartheid, où il y avait des conflits terribles sociaux dans la boîte, et il avait des missions super ambitieuses d'amélioration de la qualité. Et donc, deux points importants, parce que c'est radical quality improvement, Dantotsu, qui est la méthode qu'il a développée, ça veut dire meilleur que les meilleurs. Donc, il y avait vraiment l'intention d'être très loin devant les concurrents sur les notions de qualité. Et donc, deux choses dont on voulait vous partager, je vous inviterai à lire le bouquin si ça vous intéresse.

4:23 D'abord sur les objectifs, son programme vise de réduire de 88% les défauts, en l'occurrence par véhicule produit, en 3 ans. En gros, je les divise par deux tous les ans. Donc c'est super ambitieux, évidemment, si on imagine un petit peu obtenir les mêmes résultats chez nous, on commence par 100 bugs, 3 ans après j'en ai plus que 22, 3 ans après j'en ai plus que 1, 2 ou 3. Donc c'est vraiment, il faut imaginer que ce programme-là, il arrivait à le répéter 3 fois dans une usine, et à la fin l'usine, ça n'avait rien à voir avec ce qu'il produisait avant. Donc ça, c'est plus la radicalité d'un point de vue performance. Et donc, il y a aussi une radicalité d'un point de vue méthode. Donc, huit étapes qui sont menées par le team leader. Donc, une usine, comment ça s'organise? Il y a des groupes d'opérateurs qui travaillent sur des pièces. Il y a un team leader qui travaille avec 6 à 10 opérateurs. Généralement, le team leader est chargé à chaque défaut de faire ça. C'est-à-dire qu'il va regarder la pièce défectueuse. Donc, ça peut être un capot cabossé. Il va regarder partout ailleurs dans le stock de l'usine, voir s'il n'y a pas des pièces similaires qui ont le défaut.

5:27 Il va investiguer les causes racines, qu'est-ce qui a amené à l'apparition de ce défaut. Implémenter des contre-mesures, le daily qui s'appelle dans Dantotsu la Saichi Meeting, c'est un daily où on va plutôt faire un retour d'expérience sur la résolution du défaut, qu'est-ce qu'on a appris, quelles contre-mesures on a mis en place. Il y a un déploiement de l'apprentissage dans toute l'usine, et ça c'est la fonction QA qui est plutôt responsable de cette partie-là. Il y a de la formation des gens, il y a des vérifications. Et donc ce qui est assez extrême là-dedans, il faut imaginer que ça s'est fait sur tous les défauts, déjà ces huit étapes, et ça doit être fait en 24 heures avec la détection du défaut. Donc il y a vraiment... Quand on imagine plutôt ce qu'on fait généralement dans une boîte tech, on va trouver un bug, on va l'analyser, on va le prioriser. Des fois, on va le corriger des semaines après parce que ça va dans le sprint dans trois semaines. Parfois, je fais un post-mortem et c'est vraiment quand c'est super grave. Et alors, les contre-mesures des post-mortem, on les planifie pour Q3. Donc, c'est vraiment, il n'y a pas du tout les mêmes échelles de temps sur ce qui est fait. Et donc, j'ai trouvé ça assez intéressant de dire comment on peut tendre vers ça.

6:28 Et donc là, on va... On va aller dans une étape en particulier avec vous, qui est ce workshop, qui est quel est l'outil qu'ils utilisent pour analyser les défauts, donc apprendre des défauts, parce qu'on a essayé de transposer ce qu'ils font là-dessus dans la tech, comment ça s'applique, donc il y a des différences, il y a des points communs. Et donc, je vais te donner la main. Merci. Voilà, donc le but, vous l'aurez compris, c'est vraiment d'enlever cette pression de la performance et de créer vraiment les conditions pour être dans une zone d'apprentissage, dans une zone safe où on va pouvoir vraiment creuser les choses en profondeur. Et donc le support qu'ils utilisent, le support d'apprentissage, ça va être cette pièce-là comme analyse. Et on va la construire petit à petit en expliquant les points de contrôle avec vous. Donc la première chose à laquelle on va regarder, c'est l'environnement de détection du défaut. Si vous avez suivi le talk, il y a A, B, C, D, en tout cas chez Okla.

7:29 Et nous, en fait, on a essayé de garder les étapes un certain nombre très limitées, mais on a quand même cinq étapes qu'on va distinguer. Donc le premier, c'est le développeur. Vraiment, quand il code, il se rend compte qu'il n'a pas centré son texte. Alors il pensait que TextLineCenter, ça allait marcher, puis ça n'a pas marché. Donc ça, c'est vraiment le meilleur défaut. C'est vraiment ce qu'on cherche à obtenir. C'est que le développeur fait son auto-qualité lui-même et trouve instantanément. Et en fait, on voit que ça va limiter le rework un maximum, puisque plus on le détecte tard, plus quand le ticket va revenir, il va devoir repasser toutes les étapes. En fait, on va redéranger chaque personne dans la suite du process deux fois, trois fois, à chaque fois qu'on a un défaut. Donc là, c'est vraiment le Saint Graal, c'est vraiment la première étape. Ensuite, dans le reste du flux, on peut avoir la code review. Ça, c'est l'étape B.

8:31 C'est en fait une autre personne que moi-même va trouver le défaut au sein de l'équipe technique. Évidemment, il y a toujours des checks de qualité qui sont faits. Souvent, il y a une recette, donc le PO ou la QA. Donc ça, c'est un défaut de type C. Et là, cette barrière-là, c'est la barrière de la prod. Vraiment importante puisque tous les défauts ABC vont beaucoup moins impacter le client ou en tout cas l'utilisateur final puisqu'ils ne vont pas atteindre l'environnement de production. Ensuite, on peut se rendre compte d'un défaut en production, on a le sentry, de l'alerting. Et après, le pire du pire, en fait, en ligne, puisque c'est vraiment tout ce qu'on cherche à faire, c'est pour la satisfaction client. Et donc là, le pire des cas, c'est qu'il y a un utilisateur qui se plaint. Et donc, il faut imaginer aussi que pour un utilisateur qui se plaint, sans doute qu'il y a 100 personnes qui ont eu le même défaut, qui ont vu ce bug-là en production, etc. Pour Toyota, ce qui est intéressant, c'est que les D et les E, ils leur coûtent super cher parce qu'il y a effectivement plus de rewards.

9:35 Mais quand le client te renvoie une pièce, tu as des pénalités. Ce qui n'est pas toujours le cas dans l'univers de la tech. Ça montre qu'on est quand même généralement moins concurrentiel. Donc, il y a vraiment une intention d'éradiquer les D et les E et les faire remonter de plus en plus tôt dans le flux. Et on peut retrouver ça, effectivement, on en entend parler à chaque fois, s'il y a un défaut sur les freins, telle marque de voiture va rendre... 300 000 véhicules, etc. Donc c'est quand même des gros gros impacts. On l'a moins dans le monde du web, parce qu'en fait on peut redéployer assez rapidement, mais dans le monde de la blockchain, justement quand il y a des smart contracts qui sont déployés, une fois que c'est dans la blockchain, c'est à vie. Donc c'est pareil, on va avoir des problématiques similaire à rappel de véhicule, c'est difficile, plus impactant. Tu ne peux pas rappeler ton smart contract. Tu ne peux pas le rappeler. Donc la première chose qu'on va remplir du coup, c'est on va décrire le problème.

10:38 Donc pour nous, un défaut, un bug, c'est un comportement inattendu. On ne va pas préjuger du fait que c'est vraiment la faute du développeur, c'est mal codé, ou alors c'est une spécification qui n'a jamais été demandée par le product owner ou quoi. Vraiment, on se dit que tout comportement inattendu vaut le coup d'être étudié. Et donc, on insiste sur le fait que ce soit du point de vue du utilisateur. Si vous voyez dans vos analyses erreur 500 sur telle API, on ne se rend pas compte et je pense que toutes les erreurs 500 ne se valent pas. Et donc, en fait, ça permet vraiment de développer chez les équipes le sens client. Pour ceux qui connaissent Team Topologies, il y a différentes typologies d'équipes. Il y a les Stream Align qui sont vraiment sur le front. sur le front-end, qui sont tirés par le besoin métier. Donc eux, souvent, le sens client, ils l'ont. Mais les bandits de contexte, quand on est responsable d'une API, souvent, on ne voit pas quel est l'impact.

11:43 Et donc, le fait de faire l'effort, de trouver, OK, moi, je suis owner de cette API, j'ai une 500 sur mon API, mais en fait, ça va augmenter la compréhension de où est-ce que je me situe dans la chaîne, quelle valeur je crée pour le client. Je suis un grand militant que les développeurs aient accès aux Zendesk, par exemple. Parce que je pense que voir les mots de l'utilisateur lorsqu'il a eu un problème, c'est vraiment un point clé pour développer cette empathie, ce sens client des développeurs. Quand ça passe par le Customer Success Manager et le PO, à la fin, tu n'as plus qu'une description très aride du problème qui arrive à l'utilisateur. Exactement, pour renforcer vraiment l'empathie et puis ça crée du sens pour le travail. Alors peut-être on va un peu vous solliciter sur la partie cause, mais n'hésitez pas si vous avez des questions ou des remarques à intervenir en live comme c'est un workshop. Voilà, je laisse, si vous avez des questions, des opportunités. Donc la ligne de code, évidemment, est très très importante.

12:44 Souvent, il y a plusieurs lignes de code qu'on va pouvoir choisir. Si par exemple il y a une erreur 500, il y a le log qui donne directement, voilà, null pointer exception, telle classe, point, telle ligne. Mais ça, ça va être vraiment peut-être le point de cause. Des fois, il y a d'autres causes plus en amont qu'on va pouvoir chercher. L'idée derrière la ligne de code, c'est deux choses. La première, c'est en tant que manager, nous, en fait, on va voir du code. Parce que tout ça, c'est une interface imparfaite qui représente la réalité. Mais souvent, quand on voit le code, pour ceux qui ont codé avant, on va revoir, ça va redéclencher nos réflexes, on va regarder le naming, on va regarder d'autres choses, on va se rendre compte des énormités potentielles ou des idées fausses, on va les voir directement sur le terrain. Et l'autre chose, c'est de forcer le développeur qui va faire cette analyse d'avoir une opinion.

13:47 On va lui dire, à ton avis, quelle est la ligne? Et on va justement pouvoir mieux comprendre qu'est-ce que cette personne a dans la tête, qu'est-ce qu'elle comprend, qu'est-ce qu'elle ne comprend pas, quelles sont les zones d'ombre dans son apprentissage sur lesquelles on va pouvoir l'aiguiller. Donc là, sur le bug, On parle, alors c'est vrai que je n'ai pas parlé, mais sur la page récap du prêt, le dirigeant voit un montant qui est 1000 fois inférieur au montant réel. Donc au lieu de mettre on vous a prêté 100 000 euros, il voit on vous a prêté 100 euros. Ce qui n'est pas top. Ce qui est bien mais pas top. Pour du crédit B2B, ce n'est pas génial. Voilà, donc en fait, on va aller vraiment au niveau de la ligne de code, donc loan2insuremapper.java, et on va pouvoir tout regarder. En fait, tiens, il y a des annotations, il y a le mot-clé statique, public, private, est-ce que c'est bien utilisé? Loan2insure DTO, on regarde les patterns de code qui sont utilisés, on regarde le naming, on regarde effectivement comment on imprime les choses, est-ce qu'il y a des choses qui sont choquantes, pas choquantes?

14:48 Et évidemment, on demande aux développeurs, à ton avis, pourquoi il y a eu le bug. Donc là, ce qui est intéressant, c'est qu'on consomme une API externe qui expose un montant qui n'est pas en euros. mais en centaines de milliers d'euros. En cas d'euros, pardon. En cas d'euros. En milliers d'euros. Et donc, nous, en l'utilisant et sans le transformer et en l'affichant directement sur le front, c'est à ce moment-là qu'on introduit l'erreur. Je vous laisse un petit peu commenter. Est-ce que vous avez d'autres choses que vous aimeriez demander aux développeurs? Il y a des zones que vous aimeriez investiguer? Ou est-ce que ça, ça vous suffit? L'idée là, c'est qu'on va faire une... Lorsqu'on a un bug, on a généralement un arbre causal. C'est-à-dire qu'il y a plein de raisons qui ont amené à l'apparition du bug. Il y a la qualité du code dans lequel le développeur lui a demandé de coder.

15:51 Il y a à quel point le code qu'il a écrit a été défensif. Il y a plein de facteurs qui sont externes à l'équipe. Souvent, d'ailleurs, les réflexes des développeurs, c'est« ce jour-là, on a eu telle pression du delivery». Donc, il y a plein de facteurs. Et donc là, quels sont pour vous, sur ce bug, si vous l'avez déjà bien compris, quels seraient pour vous les facteurs qui ont pu laisser cette apparition? Sachant qu'en gros, le sujet qui se passe, c'est que notre API consomme une API d'une dépendance extérieure qui expose des montants en centaines de milliers d'euros. Sous la forme d'une chaîne de caractère. Et donc... La personne qui a fait le... Le barceur qui fait les CED sur le site commercial, elle aurait pu lui appeler la valeur montant en cas d'euros. Alors, je le répète pour la rediffusion, la personne qui a mis ici montant aurait pu mettre montant en cas d'euros. Et effectivement, c'est une excellente remarque parce qu'on voit la ligne juste en dessous. Je ne sais pas si vous voyez, mais là, il y a marqué« durée du financement en mois».

16:55 Et en fait, le développeur qui a exposé cette API, il s'est posé la question sur durée du financement. Il s'est dit, est-ce que je la mets en année, un an, trois ans? Je mets en mois, 12 mois, 36 mois. Et du coup, ici, c'est explicite pour la durée, mais pour le montant. C'est vrai qu'en plus, montant, on pourrait se dire... Montant en euros, montant en dollars, montant en... Ça va être un value object en gros. Exactement, ouais. Donc là, on a déjà deux choses qui ressortent. Il y a le nommage, une piste. Il y a le DDD, tactique. Qui ressort. On commence à voir apparaître des points d'apprentissage. Est-ce que vous voyez d'autres choses? Oui, j'allais dire un petit peu la même chose. C'est vrai que souvent, c'est un smel qui s'appelle primitive obsession. On retrouve dans presque toutes les équipes, on utilise des chaînes de caractère, des entiers ou des doubles pour manipuler des choses parce qu'on dit que c'est très simple, c'est justement une chaîne de caractère. Et en réalité, il faut encapsuler tout ce comportement de est-ce que c'est un mutant qui est dans un pur en silo en particulier, etc. Et il y a plein de bugs qu'on a pu voir aussi dans les entreprises qui ont travaillé, qui sont dus à ça.

18:00 Donc effectivement, ce n'est pas illogique que ça pose problème à un développeur qui arrive ici, qui veut juste afficher... Effectivement, on peut se dire qu'il y a un anti-pattern qui est primitive obsession. On a des remèdes, d'ailleurs des refactoring spécifiques qui permettent d'adresser ça. Je répète, mais donc pour la rediffusion. Mais effectivement, une bonne pratique, c'est d'encapsuler du coup le montant dès qu'on a quelque chose de monétaire et de préciser la currency avec... Par exemple, un trigramme EUR pour dire ça en euros, etc. Puisque dans les monnaies, il peut y avoir... Il y a des gens de Paylead également. Il y a des monnaies où il n'y a pas de partie centime, par exemple. Donc, divisé par typiquement les yens, ce genre de choses, il n'y a pas de sous-division. Et parfois, juste multiplier par mille, ça marche pour 89% des monnaies, mais le jour où on signe le dernier pourcent, c'est plus.

19:01 Oui, exactement. Puis même en termes monétaires, nous, on a l'habitude d'avoir deux chiffres après la virgule. Bon, évidemment, les flottes, pour manipuler, faire des additions, soustractions, c'est KO. Mais effectivement, on peut se poser la question de la précision. Est-ce qu'on va à 5 chiffres après la virgule pour pouvoir faire des opérations ensuite sur beaucoup de volumes quand on achète effectivement un boulon? Si le boulon coûte 1 euro pour 10 000 pièces, tout de suite la précision derrière des chiffres après la virgule est très importante. Parce que là, l'idée, c'est de regarder uniquement des problèmes potentiels en lien avec la situation. Ou de se dire, si on va regarder ça, et en fait, la ligne de cure, pourquoi est-ce que je suis en train de formater, de faire du formatage dans un DT ou un Paris, pour un truc qui n'a rien à voir? Exactement. Donc, est-ce qu'on va plus loin? Ou est-ce qu'on reste? Ça n'a pas de lien avec notre incident, les lignes de cure. Mais est-ce que c'est comme ça? Ou est-ce qu'on dit, on en profite aussi pour... La question que les gens entendent, c'était en replay, c'est est-ce que je vais me limiter à vraiment analyser les causes sur cette ligne ou est-ce que je m'intéresse à un contexte un peu plus large?

20:15 En lien avec l'incident. En lien avec l'incident. Et donc en fait, il y a cette première phase qu'on est un petit peu en train de faire ensemble. Généralement, moi j'aime bien que l'équipe technique soit là en entier pour avoir cette phase de brainstorm. Et donc je trouve que les conditions, c'est-à-dire l'état dans lequel était le code quand j'arrive, impacte fortement ma capacité à trouver des bugs. Je dis souvent, est-ce qu'on t'a demandé de coder dans un champ de mine ou bien dans une zone qui est clean où tu comprends ce que tu fais? Et donc là, typiquement, si ce truc-là existait déjà et qu'il a rajouté le montant, le fait d'avoir d'un point de vue separation of concerns un truc foireux, on sait que ça crée de la charge cognitive et que ça favorise l'apparition de bugs. Donc on pourrait le regarder. Donc là, on a du solide aussi. Le fait qu'il y ait du français et de l'anglais, ça... Charge cognitive aussi. Voilà, mais c'est un aspect DDD, genre je respecte le langage parlé, le WQT language, ou tout simplement... Parce que là, si on tient, il faut réécrire tout le code, remettre... Tu peux te dire, ça, en fait, je devrais l'archiver.

21:18 J'ai cette dépendance d'API qui, en fait, a décidé de nommer ces variables en français. Donc j'ai besoin d'avoir un anti-corruption layer qui va me le transformer. Et donc je pourrais avoir une classe dont c'est le rôle de se dire, je prends les variables en français, je les renomme en anglais parce que dans mon code, je manipule de l'anglais, ce qui était le cas pour nous. Donc ça, c'est une sous-partie de nommage. On peut se dire qu'il y a un sujet de nommage sur l'unité. On pourrait choisir de mettre l'unité dans le champ. Il y a aussi un sujet de ce que c'est du français, ce que c'est de l'anglais. On est un peu sur le DDD. Je propose d'avancer, puisque le workshop arrive. Mais donc en fait, on a quand même, vous voyez sur un bug qui paraît assez simple, en fait on arrive à avoir des discussions qui sont assez larges sur le craft. Et une des intentions importantes de cette analyse de bug, c'est effectivement en faire une zone d'apprentissage. Ce n'est pas une zone où on veut blâmer la personne d'avoir introduit le bug, c'est en fait une opportunité d'avoir des discussions et de step up sur différentes parties de notre métier. Oui, bien sûr.

22:18 Comment vous gérez la tension entre le fait qu'on a un bug de probe, Il y a forcément beaucoup de pression, des cas euros qui partent. Et l'apprentissage, ça suppose du temps. Donc ce qu'on fait est un peu différent. La question c'était comment on gère la pression par rapport au fait de faire ces analyses. Déjà, d'apprendre ces choses-là. C'est une situation d'apprentissage qui prend du temps et qui du coup va retarder la production du bug. Ce qu'on a décidé de faire, c'est de faire ces analyses-là uniquement quand le bug a été fixé. De façon à éviter, donc on ne le fait que quand le bug a été corrigé. Parfois c'est une correction temporaire qui protège le client, mais en tout cas on ne le fait jamais quand l'incident est ouvert. Parce qu'on sait, et je trouve ça plutôt bien, la prod c'est quand même important, que la personne ne va pas avoir la capacité de réfléchir à ça si elle est en train d'éteindre un feu. Exactement, on protège le client, on éteint le feu, et après on analyse. Et souvent dans l'analyse, on se rend compte que le fixe n'est pas bon, n'est pas le meilleur, parce qu'on a essayé en trois heures de faire le meilleur fixe, et oui, ça a éteint le feu, mais effectivement sur le long terme, ce n'est pas la bonne chose à faire.

23:23 Ensuite, on arrive à la partie cause parce qu'on a ouvert l'entonnoir par cette discussion. On a évoqué, généralement, l'équipe a plein d'idées sur les causes d'occurrence. C'est une première cause qui est pourquoi est-ce qu'on a introduit ce défaut. Et donc, on demande à la personne qui fait l'analyse de choisir parmi cet arbre causal un sujet d'apprentissage. C'est souvent le tech lead qui fait ça. Il va se dire, en fait, il y a cinq facteurs. Je vais en choisir un sur lequel je vais mettre de l'intensité parce que ça me semble intéressant et l'équipe va être motivée. Donc là, on en a choisi une, qui était que Loïc qui a codé ce code-là. n'avait pas de standard sur comment gérer les montants. Ce qui peut vous surprendre là-dedans, c'est qu'on met le prénom de la personne. Et en fait, ça, ça marche uniquement si ces moments-là, c'est des moments d'apprentissage. C'est-à-dire qu'on se dit, Loïc, comment est-ce qu'on fait pour l'aider sur ce sujet? Comment on fait pour le former? Si en fait, ce moment a été associé à un moment de performance et d'évaluation de la performance, c'est évidemment hyper mal vécu parce que c'est vécu comme du blame. Donc il faut créer, moi quand je fais ces sessions, je fais une ou deux sessions par semaine avec les développeurs, c'est des sessions où j'ai un vocabulaire très positif autour des bugs.

24:28 Je dis que c'est des moments d'apprentissage, c'est génial, on va apprendre plein de trucs. Et ça, ça permet de se dire que c'est quand même Loïc qu'on peut aider sur ce sujet et qu'est-ce qu'on peut proposer à Loïc pour se former, pour l'aider, des dojos, des formations, des katas, des choses comme ça. Donc on a choisi ce point-là, et donc on en choisit une seule parce qu'on veut que ce soit rapide, donc ça prenne 30 minutes de faire ça. C'est un des points clés, si on veut arriver un jour à faire comme Dan Totsu, tous les défauts en 24 heures, on a besoin que ce soit un geste rapide. Et donc la cause d'occurrence, c'est ce que je disais là, on doit vraiment le point de contrôle de cette... cette zone-là, c'est qu'on a identifié qui doit apprendre quoi. Et en fait, cette question-là, je trouve dans les post-mortem, elle est assez rarement posée. Souvent, on va se poser la question de quelles sont les zones d'inspection qui manquent. On va dire, il n'y avait pas assez de tests, il n'y avait pas assez de code review. Là, on veut vraiment identifier un savoir-faire qui manquait à quelqu'un et qu'on va pouvoir apporter. Là, en l'occurrence, on était sur un cas où, On s'est rendu compte qu'il n'y a pas que l'OIC, c'est-à-dire que globalement, on n'était pas au clair sur quelle était la meilleure manière de stocker et de se trimballer des montants dans une application dans le domaine métier, le financement B2B.

25:30 C'était un peu une zone d'apprentissage commune. Et donc on va faire apparaître généralement des contre-mesures qui vont soit viser à améliorer les matières premières qui sont arrivées aux développeurs. Donc là, ça aurait pu être l'aspect d'API de la dépendance qui ne précisait même pas que c'était en centaines de milliers d'euros. Donc on a un sujet de matière première. L'OpenAPI, ce n'était pas ça. C'était un doc word qui ne précisait pas. On peut avoir des sujets d'outillage, parfois la personne est mal équipée, donc les contre-mesures intéressantes, ça va être de l'équiper davantage. Ça peut être des sujets de formation, ça c'est un cas où il y a un standard qui existe et qui est connu, mais la personne n'a pas été formée à ce standard. Et ensuite on a des sujets, et c'était notre cas ici, de méthode, où en fait on ne s'était pas mis d'accord collectivement sur quelle était la bonne manière. De faire ce geste. Donc c'est les 4 M en ligne qui sont un bon frame pour identifier des causes type, des contre-mesures type. Et donc là, on a fait apparaître des contre-mesures. Les points de contrôle, c'est qu'on veut que l'équipe soit autonome pour pouvoir les mener. On ne veut pas que ça demande de diffuser quelque chose de large, parce qu'on ne veut que mettre une dynamique positive. Et donc là, ça a été assez intéressant parce qu'on est allé regarder, Loïc est allé regarder ce que faisaient les acteurs qu'on considère comme étant bons sur les sujets d'API, donc Stripe, à repérer que Stripe ne stockait pas les montants

26:42 en chaînes de caractère et en centaines de milliers d'euros, il les stockait en centimes et des entiers. Et donc on a pu avoir une discussion avec le client qui nous a expliqué que ça, c'était bien adapté pour le paiement, mais pas pour le financement, parce qu'on pouvait avoir des montants qui étaient, c'est un peu la discussion qu'on a eu tout à l'heure, qui étaient en flottant. Donc ça nous a fait émerger un standard, du coup, qu'on a pu ensuite utiliser pour former l'équipe. Et du coup, sur une analyse de bug, il y a toujours deux questions qu'on se pose. La première et la plus puissante est celle sur laquelle on passe le plus de temps. Ça va être la cause d'occurrence. Qu'est-ce qui fait qu'on a introduit ce bug? On va regarder vraiment au niveau de la ligne de code. Quand le développeur dans l'IDE, il a écrit sa ligne, il finit par point virgule, il tape entrée, paf, ça y est, le défaut a été introduit. Et ensuite, on va se poser la question de qu'est-ce qu'on peut faire pour le détecter plus tôt. Comme on l'a vu sur le flux, A, B, C, D, E, plus on le détecte tôt, moins il y a de rework. Là où nous on a un parti pris, c'est de choisir, parce qu'en fait, quand un bug est allé jusqu'à la production, il y a un trou dans la raquette, mais en fait, il y a 20 trous dans 20 raquettes.

27:49 C'est-à-dire que ça a passé les tests unitaires, ça a passé les tests d'intégration, ça a passé les tests end-to-end, ça a passé la code review, la recette manuelle. Essentiellement, si vous avez un premier environnement, puis la pré-prod, puis la production, on pourrait faire 20 résolutions de problèmes à chaque étape. Et donc notre partie prise là-dedans, c'est de s'arrêter à la première et de choisir et de favoriser les résolutions qui sont dans la première. Donc idéalement, directement dans l'IDE du développeur, c'est vraiment ce qu'on cherche à avoir. Et on aime bien également quand c'est bloquant, c'est un petit peu un retour d'expérience. C'est qu'au début, quand on a commencé à faire du dent au-dessous, On a mis en place des pré-commit hooks, etc., des choses comme ça. Mais quand, par exemple, le pré-commit hook met trois secondes, les développeurs, ça les gêne. Et donc, du coup, ils se créent eux-mêmes leurs alias Git avec moins moins nos verify.

28:50 Et donc, en fait, même si nous, on essaye de mettre en place des bonnes pratiques, les développeurs vont quand même résister. Donc on essaye d'avoir des choses qui sont vraiment bloquantes, donc plutôt dans la CI, pour être sûr qu'on ne puisse pas tendre le système. Il y a quand même des nouveaux problèmes sur comment est-ce qu'on fait pour ne pas avoir trop de lourdeur, trop de choses bloquantes que les gens ne comprennent pas. Donc c'est toujours un équilibre qu'il faut réussir à maintenir. Et effectivement, c'est vraiment pour ça qu'on se focalise principalement sur l'introduction. Parce que sur la cause d'outflow, le piège, c'est qu'on va vouloir... rajouter bureaucratiquement d'autres étapes, on va vouloir rajouter des checks qui vont en fait freiner l'équipe, enlever de l'agilité, rajouter de la bureaucratie. Donc on s'en méfie et on essaie de bien comprendre les tenants et les aboutissants pour prendre les meilleures décisions pour chaque contexte. Voilà, du coup si vous avez d'autres questions sur l'analyse, évidemment on reste disponible après le workshop.

29:56 Là on a fait un zoom juste sur ce support d'apprentissage. qui était le format d'analyse de pièces, un petit retour d'expérience sur ce qu'on en a fait à Sipios et à Theodo. Un petit dernier point, ça a eu quand même des bons résultats, l'équipe pilote avec laquelle on a lancé ça a quand même en 9 mois réduit de 81% les défauts en production qu'ils introduisaient. Je ne parle pas de stock, je parle vraiment de volume in. Donc ça a demandé du temps. Il y a eu plein d'itérations sur ce format, dont je ne parlerai pas. Si vous voulez en savoir plus, j'ai fait un talk à Flocon il n'y a pas longtemps où je détaille davantage la théorie. En tout cas, ça fonctionne bien, cette méthode, et ça crée des discussions, je trouve, de beaucoup plus haut niveau qu'avant. Avant, c'était« je n'ai pas le temps» ou« je suis pressurisé». Maintenant, c'est« je ne connaissais pas bien le refactoring extract function» de Martin Fowler. Donc, ce n'est pas du tout les mêmes discussions. Vous faites ça sur tous les bugs, en val A, B, C, D, E? La question c'était est-ce qu'on les fait sur tous? Aujourd'hui non. Aujourd'hui on est assez loin du 8-step, on le fait sur chacun. On le fait aujourd'hui sur ce projet-là, on le fait sur les incidents, qui sont aujourd'hui des défauts qui sont considérés comme, déjà c'est au moins des D ou des E,

31:06 C'est des défauts qui sont considérés comme étant suffisamment impactants pour que vraiment ça vaille le coup de se poser la question de qu'est-ce qu'il y a à apprendre. Il y a une vraie question sur le rythme. Et comme notre intention, c'est l'apprentissage, grosso modo, c'est bien si chaque personne en a une en cours à chaque instant. Après, il ne peut pas en faire deux ou trois en WIP en même temps, ce n'est pas bon. Mais s'il en a une par semaine ou une tous les deux, trois jours et que chaque personne en fait régulièrement un petit peu. C'est pour ça que le template est assez light aussi. C'est vraiment ça qu'on cherche à atteindre, c'est l'intention. Bonne question. C'est-à-dire sur les contre-mesures qui sont amenées ou sur l'analyse? Sur les capacités paniques. Quel est le budget? La question, c'est quel est le budget d'apprentissage? 30%, 50%. Je pense qu'il y a deux choses. Il y a parfois des sujets qui sont vraiment des... Par exemple, je dois résoudre un problème de dette technique qui prend du temps. Donc ça, on va le planifier comme un sujet fonctionnel.

32:07 Ensuite, le day-to-day, on utilise une philosophie qui s'appelle Kaizen en ligne. Donc l'idée, c'est généralement une équipe, on veut qu'elle ait 30 minutes par jour pour faire des améliorations. À ça, ça ajoute le fait qu'on veut qu'il y ait du boy scout dans chaque pull request. Mais on pense que c'est le minimum pour avoir une équipe qui est apprenante. C'est 30 minutes. Le format, au début, ça prenait 3 heures, parce qu'il y avait beaucoup plus de cases. Donc on a itéré parce qu'on peut être capable qu'une personne qui est formée à faire ce geste soit capable de le faire en entier en 30 minutes. Après, il y a les contre-mesures à prendre qui peuvent prendre du temps, mais qu'on essaye de rendre assez frugal aussi. Mais en tout cas, ce process que vous avez vu, on est capable aujourd'hui de le faire en 30 minutes. Qui c'est qui anime justement? C'est plutôt le tech lead, ce serait plutôt l'engineering manager, ce serait plutôt le coach ou le scrum master, j'en sais rien. Qu'est-ce qui a le mieux marché dans l'animation? Nous, c'est l'engineering manager puisqu'il en a vu pas mal. En fait, lui forme le tech lead pour qu'ensuite le tech lead soit formateur à son tour.

33:10 Alors il faut savoir que dans Dan Totsu, ces daily meetings dont je parlais, où ils racontent, ils font le retour d'expérience et s'analysent, le CEO est au meeting. Donc il y a tout un tas de trucs qui montrent qu'on voit la scène, on voit toutes les pièces défectueuses par terre, et tu as le CEO qui est là, et les mecs racontent comment ils ont résolu le défaut, qu'est-ce qu'ils ont appris, qu'est-ce qu'ils ont mis en place. Donc il y a vraiment une intensité super forte. Et effectivement, comme c'est un moment d'apprentissage, là on a zoomé que sur la fiche, mais c'est le tech lead qui est au daily suivant. Donc il y a le daily de l'équipe et ensuite il y a le Rex où il va justement présenter cette fiche-là le lendemain, tout de suite après. Le rythme, on essaye de faire que ce soit quotidien. Après, on a tellement peu de bugs qu'on ne peut pas tenir le rythme quotidien, mais on aimerait. Le problème, c'est que vous n'avez plus de bugs, vous n'attendez plus rien. Du coup, on remonte au A. On remonte la chaîne. C'est des bugs de type A ensuite. Donc le A, c'est quand même très différent parce que le A, c'est vraiment, pour ceux qui ont vu le talk de tout à l'heure, le développeur, en fait, code à l'aveugle.

34:24 Il ne code qu'en TDD. Il n'a pas le droit de lancer l'API et le front. C'est juste au moment où il se dit qu'il est prêt à pousser son code, qu'il a le droit de lancer l'API et le front et de voir si ça marche. Donc c'est à ce moment-là qu'il log. Le problème, si soit ça a marché du premier coup et il y a une fête, il y a une champagne, il y a une couronne, je sais, chez Ocla, soit il y a un défaut et du coup le développeur va faire cette analyse-là, mais sur un A. Et donc ça dépend, je pense que c'est deux stratégies qu'on a testées différentes. Nous, on est plutôt parti des D parce qu'on avait des gros problèmes de production. On s'est dit que c'est le premier truc à faire. Thomas, que vous avez vu tout à l'heure, s'est dit je vais partir des A. En fait, je me rends compte qu'il y a des équipes. On a eu un bug sur deux mois et là, on remonte. En fait, on a eu un D sur un mot deux mois. Donc, on remonte la chaîne de valeur. Et juste une question de curiosité, le profil des engineering managers, c'est comment? C'est des purs managers ou ils ont encore cette casquette technique? Ils codent également. Ils ont codé, ils codent de moins en moins, mais ils ont un background de code.

35:26 Parce qu'on voit les questions qui se posent quand on est sur le terrain. On regarde la pull request, on lit le code. En fait, ça déclenche plein de réflexes que la personne doit avoir acquis précédemment. Pour les transmettre, c'est de la transmission de savoir également. En tout cas, chez nous, on a fait le parti pris que les EM ont eu besoin d'avoir beaucoup codé à un moment. Il y a un truc qui me paraît aussi difficile, c'est sur certains... Là, on voit la séance peut durer 30 minutes, mais la recherche de la route cause pour alimenter le format, ça peut prendre deux jours. Donc, c'est peut-être même cet aspect-là qui est le plus chronophage, j'imagine. En fait, notre partie prix, justement, c'est comme on en fait tous les jours, les gens vont de plus en plus vite ensuite. Ils savent en fait quelle est l'intention, pourquoi on cherche la ligne de code. Ils ont des réflexes aussi qui sont beaucoup plus rapides pour regarder. Parce qu'au début, on le fait, les gens ne vont pas forcément regarder dans le log le point de cause, la classe, etc.

36:29 Et puis en fait, c'est... Plus on le fait, plus on arrive à aller vite. Au début, je pense que ça prenait plutôt 3-4 heures, et puis après 2 heures, et là on essaie de faire... Bon, 30 minutes c'est ambitieux, moi en tout cas dans mes équipes c'est 1 heure à peu près, et Woody arrive avec ses équipes à faire en 30 minutes. Je pense que peut-être un point qui est important, ce qui a fait que ça s'est réduit le temps, c'est que les gens se sont constitués des modèles mentaux. En fait, là, on a listé plein de modèles mentaux, les principes dry, solide, refactoring, tout ça. Et en fait, en regardant la ligne de code, on voit qu'ils analysent la ligne de code par rapport à ces modèles mentaux. Et en fait, ça va souvent assez vite maintenant pour les équipes qui ont développé ça. Donc, c'est au bout de combien de temps le processus ? Dans Dantotsu, dans l'industrie, c'est des programmes de 3 ans, moins 88% en 3 ans. Là, ce qu'on a constaté avec l'équipe pilote avec laquelle j'ai lancé, c'était en début d'année, on a diminué de 81% en 3 trimestres.

37:40 Donc ça a quand même pas mal marché. Ensuite, il y en a qui sont remontés en C, B, A. Il y en a qui ont disparu. Parce qu'on fait deux choses en même temps. C'est-à-dire qu'on évite d'en introduire. Il y en a certains qu'on détecte plus tôt. Voilà, le talk est fini. On vous propose d'en rediscuter autour d'un café après. Merci.