Woody Rousseau et Flavian Hautbois - Qualité radicale

[00:00:05] Bonjour tout le monde. On va être le talk qui va faire le parallèle entre la tech et l'industrie. et donc c'est assez amusant parce que pour la première fois quand on quand on a lu le bouquin dont on va vous parler la personne de Toyota décrivait ce qu'elle a fait comme de l'extrême programming pour l'industrie. Donc pour une fois ça s'est fait un peu dans l'autre sens. Et donc on est là pour vous parler de qualité, aujourd'hui de qualité radicale. Et donc pour commencer,
[00:00:30] On déteste tous les bugs. les bugs, ça nous pourrit la vie depuis les applications qu'on utilise, au conseiller bancaire qui essaie de faire un truc pour nous et qui y arrive pas parce que leur système fonctionne pas. Et on en produit beaucoup dans l'attaque des bugs. On se dit toujours bah c'est un peu les bugs, c'est la vie, il y a des trucs des phrases qui ressortent comme ça, c'est pas un bug, c'est une feature. Et donc on va essayer de de déconstruire un petit peu ça.
[00:00:55] Et donc ce qui est assez étonnant, c'est que les bugs c'est c'est considéré comme étant quelque chose de normal dans notre industrie et pourtant les bugs peuvent avoir des conséquences absolument délirantes. Donc je pense que vous avez entendu des des du bug qui a causé les problèmes avec la fusée Ariane. J'ai trouvé un exemple un peu plus exotique. C'est une machine qui s'appelle Therac-25 qui était une machine pour traiter des cancers, donc qui envoyait des des électrons ou des photons dans les années 80. Et donc cette machine a tué 5 ou 6 personnes parce qu'il y avait une variable globale dans le code. euh qui était euh avec une race condition, le le truc est hyper compliqué mais en tout cas ça balançait 100 fois la dose de radiation qui devait être envoyée pour soigner le patient et donc on a eu des patients qui sont morts. Donc on voit que il y a un paradoxe entre le fait que on trouve ça normal euh ce qui est moins le cas dans l'industrie et pour autant les conséquences sont graves. Et euh en fait quand quand on s'interroge sur quelle est la raison de ça, c'est que je pense qu'on a une misconception, donc une idée fausse qui est que euh la non qualité coûte moins cher que la qualité. Donc il y a un bouquin qui est pas mal. euh que j'ai lu que ça qui a été écrit par des mecs d'IBM qui s'appelle The Economics of Software Quality qui est en fait un livre qui permet d'évaluer l'impact économique de la qualité versus de la non qualité. Donc il y a ce que vous voyez en abscisse, c'est des function points. Donc c'est c'est la manière que IBM utilise pour mesurer la taille des applications. Donc plus il y a de function points, plus il y a de fonctionnalités, donc plus l'application est grosse. Et donc ils ont su faire une différence entre des projets qui avaient des pratiques de qualité élevée, donc extrême programming, euh, test et cetera versus des projets qui étaient plutôt light sur ces aspects-là. Et donc on voit que l'impact est quand même très gros pour des très grosses applications, ça se compte en plusieurs de centaines de millions d'euros. Ils ont ils ont analysé des des des milliers de projets informatiques depuis les années 80 pour avoir ces données. Et au-delà de ça, ce qu'on voit, c'est que même en pourcentage, plus l'application est grosse, plus cette différence de coût, en fait, pour produire des applis est élevée. Et donc on arrive à 25% de différence entre des pratiques de de qualité élevée et des pratiques faibles. Donc l'impact est super fort. Et je je trouve que ce bouquin a l'avantage de pouvoir mettre en lumière que cette idée fausse, en fait, elle est vraiment fausse et que faire bien du premier coup, ça coûte moins cher que euh de que de faire n'importe quoi.
[00:03:10] Ouais tout à fait. Et euh et le le livre Accelerate va même un peu plus loin que ça dans l'idée, c'est que ils regardent, ils essaient de trouver les clusters euh de de d'entreprises qui ont des bonnes pratiques et ils arrivent à faire une corrélation entre les entreprises qui sont très fortes sur
[00:03:25] ces quatre euh métriques, donc le deployment frequency, le lead time, euh le pourcentage de de déploiement qui introduisent un incident et le time pour les résoudre. Et donc ils arrivent à corréler ça avec la performance business et euh la performance euh si tu peux hop. Merci.
[00:03:44] et la performance non commerciale, c'est-à-dire la satisfaction des gens et cetera. Et donc ce premier cluster des Dora metrics montre qu'en fait les quatre autres aussi métriques sont corrélées entre elles. Plus on déploie vite, euh moins on fait moins d'incident, euh plus le time est est est faible, moins d'incident et cetera. Donc la qualité et la vitesse sont vraiment mains dans la main.
[00:04:04] Donc à partir de ce constat, on on on a décidé d'adopter une stratégie qui est la stratégie zéro zéro défaut, zéro bug. Euh et on n'a pas décidé de de l'adopter parce que on considère que c'est une fin en soi. Je pense qu'il y a un chemin énorme pour que dans dans la tech on y arrive pour de vrai. Mais en revanche,
[00:04:21] Moi j'y crois hein.
[00:04:23] Moi aussi mais dans longtemps. Mais en tout cas, on pense que c'est la meilleure stratégie pour former des équipes tech qui sont imbattables et donc qui sont meilleures que celle des concurrents. C'est-à-dire si on arrive à faire en sorte que chaque développeur mette de l'insensité tous les jours pour faire du code qui ne casse jamais, on pense que c'est un moyen vraiment de de se séparer de de la compétition et c'est c'est un c'est vraiment un concept fort dans le line et on va en parler dans peu de temps. Donc pour se présenter rapidement, donc on on a tous les deux ce ce combat du zéro bug. Donc moi je m'appelle Woody, je suis le CTO et co-fondateur de Sipios, on fait partie d'un groupe de boîtes de service, groupe Teodo. Et donc Sipios on est spécialisé sur les services financiers. Donc on fait typiquement des néobanques, des des applis Fintech. Euh et donc j'ai j'ai commencé à pratiquer euh ce dont je vais vous parler, il y a à peu près 1 an, maintenant un petit peu plus d'un an.
[00:05:10] L'idée c'est que je vous partage un retour d'expérience.
[00:05:14] Moi c'est Flavien. euh j'ai travaillé aussi pour Teodo à un moment. Euh, on a d'ailleurs travaillé un petit peu ensemble sur un projet il y a longtemps. Et après, moi j'ai j'ai j'ai un peu suivi une voie séparée, je suis devenu CTO d'une boîte qui s'appelle Appricity euh qui euh qui faisait des traitements de fertilité, où du coup les enjeux de qualité étaient énormes parce que derrière, on avait des traitements médicaux pour euh des gens qui étaient en plus c'est assez difficile psychologiquement les traitements de fertilité. Et je me suis mis à mon compte euh là récemment, je suis euh CTO par Intérim d'une d'une entreprise qui s'appelle Ocus et je co-écris un livre sur euh le développement de produits digitaux. Euh surtout sur l'angle technologique où je suis un peu un je suis toujours un geek, je code beaucoup.
[00:05:56] Et euh et donc le Lin, c'est vraiment euh pour moi une une réponse à comment on arrive à faire des équipes qui sont excellentes euh pour faire des produits excellents.
[00:06:10] Pardon, c'est moi toujours. Donc le le de quoi on va parler exactement. Donc on va commencer, donc on commence par l'angle de Toyota dans l'industrie avec Sadao Nomura. Euh, on va faire euh le pont entre ça et nos pratiques dans la tech. d'un point de vue plus général et ensuite arriver à des exemples particuliers de ce qu'on a testé Woody et moi séparément dans nos contextes. pour à la fin, sortir un un un framework assez léger que vous pouvez prendre et emporter chez vous pour le tester à la maison.
[00:06:39] Et donc on va commencer par l'industrie avec l'histoire de Sadao Nomura. Donc c'est sa tête qu'on a photoshoppé. Donc on s'excuse pour lui. Euh et donc Sadao Nomura en fait c'est je le considère comme monsieur qualité de Toyota, c'est-à-dire que c'est quelqu'un qui était envoyé par Toyota dans les usines qui produisaient trop de non qualité pour que Toyota accepte qu'ils exportent des bagnoles en fait. Donc c'était vraiment celui le le mec à appeler quand ça n'allait pas. Et donc il avait notamment euh aidé des usines en Australie, en Afrique du Sud, euh dans notamment en Afrique du Sud où il y avait des un contexte social très difficile, c'était juste après l'apartheid, il a réussi dans ce contexte-là à améliorer significativement la qualité jusqu'à ce que Toyota accepte d'exporter. Et donc là, il a écrit un bouquin qui est ce livre, euh qui est la base de tout ce qu'on a fait depuis plus d'un an, euh qui s'appelle The Toyota Way of Dantotsu. Donc Dantotsu ça veut dire better than the best, c'est-à-dire que c'est c'est l'idée de faire mieux que les meilleurs. C'est vraiment ça la philosophie de Sadao Nomura. Et il raconte ce qu'il a expérimenté dans plusieurs pays, donc en Amérique du Nord et en Europe essentiellement, inspiré aussi d'apprentissage qu'il avait eu en Australie et en Afrique du Sud.
[00:07:42] Il a fait ça à l'échelle de 11 entreprises, d'ailleurs. Et le euh le son objectif en fait, il était assez euh clair et limpide, il voulait diviser par deux le nombre de défauts euh sur les chariots élévateurs qui sortaient tous les ans. Euh, tout ça pour arriver à euh -90% de réduction en 3 ans.
[00:08:02] Donc il faut imaginer un petit peu ce que ça fait si on a si on a 100 bugs en année 1, trois 3 ans après, on en a plus que 22 et ensuite c'est ça devient vraiment ridicule. Et donc il il réussissait à faire ces programmes plusieurs fois de suite.
[00:08:14] C'est-à-dire qu'avec ces usines-là, il a réussi à faire -88 % trois fois juste dans certaines usines, donc ça ça donnait vraiment euh des gains euh gigantesques pour les usines dans lesquelles il allait bosser.
[00:08:26] Ouais tout à fait. Et un de ses guides c'était déjà de de commencer en classifiant les bugs. Donc nous on a on a tendance à classifier les bugs en importance, sévérité et cetera. Lui il a il a choisi un système assez simple, centré sur une équipe, en fait les c'est les bugs de type A, ça commence par ça, ça ça désigne la sérieité du bug. Donc s'il est attrapé dans l'équipe, il est moins sérieux parce que il a jamais été euh transmis à d'autres équipes. Le type B, bah c'est le c'est le bug que une équipe qui euh qui fait une pièce euh transfert à une équipe suivante. Le type C, c'est celui qui va être euh subi par un prestataire, par exemple euh euh voilà, j'envoie ça à une une boîte qui va qui va ensuite les livrer, si la boîte se rend compte que il y a un défaut sur le chariot élévateur, ça devient un type C. Le type D, c'est celui du client final euh voilà une de nos voitures qui euh qui a un accident, c'est le pire qui peut arriver parce que euh parce que à la fin le client doit renvoyer le chariot, il est pas content et cetera, il voit le truc. Et l'idée derrière ça c'est de de de se dire en fait tout les bugs de type D sont en fait avant ça des bugs qui des bugs des défauts qui auraient pu être du type C, B ou A.
[00:09:33] Euh, défaut c'est plus large que bug. Euh, dans on en reparlera. Euh et donc voilà, c'est ça son système pour essayer d'attirer l'attention sur la qualité.
[00:09:42] Donc évidemment, plus on va loin dans le flux, plus le défaut coûte cher. C'est-à-dire qui euh il coûte plus cher à réparer, euh il y a des procès, il y a des des réclamations qui sont parfois payées par Toyota lorsqu'il livre des dés au clients. Donc il y a vraiment une idée de
[00:09:58] euh de les catégoriser, de voir quel est l'impact sur la valeur que n'apporte pas Toyota à ses clients en faisant du A B C D. Et donc comment ils font ça, il y a il y a une idée qui est centrale dans dans le livre qui est l'idée de la procédure en huit étapes. Et donc c'est une procédure qui est euh qui est à la main du team leader. Donc la manière dont c'est organisé pour pour ceux qui connaissent pas bien. Donc il y a des dans les usines, il y a des team leaders qui vont s'occuper de 6 à 10 personnes qui sont des opérateurs, donc ils vont fabriquer les pièces. Et donc le team leader est responsable de ces huit étapes. Donc il y a une première étape où il identifie quel est le problème sur la pièce, typiquement une pièce qui est cabossée, il va aller voir dans le stock de sa zone de l'usine pour voir s'il y a pas d'autres pièces qui ont le même problème pour pouvoir les corriger également éventuellement les sauver si c'est possible, parfois c'est c'est sauvables. Il va investiguer la cause racine qui a introduit le défaut, donc est-ce que c'est un endroit où il y a par exemple un tournevis qui est abîmé et qui fait que ce défaut est installé, il va implémenter des contre-mesures qui peuvent être dans l'exemple que j'ai donné, changer le tournevis. Et ensuite il va reporter au Daily meeting le défaut résolu, donc pour expliquer ce qui a été appris de la résolution de ce défaut, quelle a été la cause, qu'est-ce qu'on a mis en œuvre pour le corriger. Mais ça s'arrête pas là.
[00:11:10] le team leader avec l'aide du département QA va déployer les apprentissages horizontalement dans toute l'usine, donc potentiellement dans d'autres procédés où des problèmes similaires peuvent se produire. Il va former les personnes, donc les opérateurs pour qu'ils puissent vraiment être formé au geste qui a qui a potentiellement fait défaut. Et puis enfin il y a des checks, ce qu'on appelle des Go & See, c'est-à-dire qu'ils vont voir sur le terrain pour voir si dans la pratique, la manière dont est fait le geste aujourd'hui est correcte. Et donc ce qui est euh euh assez frappant quand on voit ça, c'est qu'il y a vraiment une volonté de de complètement éteindre la cause du défaut. C'est-à-dire que c'est je je vois vraiment Attila, l'herbe ne repousse pas, il y a une volonté de se dire ce défaut, plus jamais dans mon usine. Et la deuxième idée qui est quand même très forte, c'est le fait que tout ça, ça doit être fait en 24 heures sur chaque défaut. C'est-à-dire qu'il faut imaginer à chaque fois qu'il y a un défaut sur une pièce, le team leader fait chacune de ces étapes jusqu'au bout, il a 24 heures pour le faire. Et donc Sadao Nomura dit une phrase qui qui m'a marqué speed, c'est-à-dire qu'en fait la vitesse est clé pour la vitesse pour la qualité.
[00:12:06] c'est-à-dire qu'en fait la vitesse est clé pour la vitesse pour la qualité. Donc on voit là les étapes dans lesquelles ça se fait, donc toutes toutes ces étapes-là jusqu'au Daily meeting en fait se font le jour où le défaut est détecté et puis toutes les autres se font le lendemain. Elles sont pas planifiées. Il dit pas, on planifie une formation dans deux semaines, c'est vraiment le lendemain que c'est fait avec l'ensemble des opérateurs.
[00:12:29] Donc il y a plusieurs autres aspects dans euh dans oui, si tu veux.
[00:12:33] Tu te mettes là parce que ça marche pas sinon.
[00:12:34] Ah ouais d'accord. Il y a il y a plusieurs autres aspects dans le dans le livre. Le premier, c'est qu'ils insistent pour réussir à arriver au zéro défaut sur le management visuel. Donc le fait de voir la delivery, de voir les problèmes. Euh pas que hein mais et ça ça marche pas du coup. Ah si pardon.
[00:12:51] Euh, le deuxième, c'est la standardisation, donc le fait de décrire en fait, c'est qu'est-ce qu'il faut savoir pour bien faire le produit.
[00:13:04] Le troisième, c'est les programmes d'entraînement, donc les dojos qui permettent de former tout le monde euh aux gestes et de le faire euh dès qu'il y en a besoin.
[00:13:11] Donc les dojos pour préciser, c'est c'est vraiment des des lignes de production qui sont répliquées dans l'usine, donc qui sont vraiment exactement les mêmes que que les les les zones où les gens produisent pour que ils produisent dans des conditions qui sont très proches de la réalité. Et quand ils arrivent à produire un niveau de qualité acceptable, ils ont le droit de passer sur la chaîne de prod.
[00:13:30] Euh, il faut aussi ce qu'ils appellent du weak point management. Alors weak point management ce sera on va voir les points avec la tech mais en gros, c'est une manière de résoudre les problèmes les plus difficiles et les plus récurrents. Euh, le change point management, c'est c'est c'est la réponse à la question, en fait, euh qu'est-ce que je dois savoir moi en tant que team leader pour que mon équipe fonctionne quand il y a des des perturbations, quand il y a des des changements, des gens qui partent en vacances, quand on change un process en amont et cetera, qu'est-ce que je dois savoir, à quoi je dois faire attention ?
[00:14:01] Et euh et ensuite le 2S, donc c'est le fait de de ils ont deux conditions sur ce qu'ils appellent le 2S. C'est euh dès que j'ai besoin d'un un opérateur qui a son ligne de production, il doit aller vite, il doit faire la qualité et cetera. Et pour le faire en fait, il doit avoir tout ce dont il a besoin à disposition en moins d'une seconde. Euh et euh sur le sur le shop floor donc là où il y a là où il travaille, dès qu'il se pose des questions sur tiens comment on fait, c'est quoi le standard pour tel truc ou tiens j'ai besoin du visual management pour pour un pour autre chose, ils peuvent avoir accès à ça en moins d'une minute.
[00:14:40] Et euh dernièrement, ils ont des rituels autour de la qualité, donc ça c'est un ce qui s'appelle un Dasaishe, c'est une réunion du matin. Donc un Daily un Daily du matin. Le Daily stand-up pour regarder les problèmes de qualité. Donc là on voit, ils ont plein de place devant eux qu'ils vont regarder, analyser.
[00:14:59] Pardon, j'ai un peu de mal avec les étapes. Euh, donc qu'est-ce que ça veut dire dans la tech ? Et donc du coup, c'est quoi le comment on va regarder la qualité et le flux dans la tech ? Le le la première manière de le regarder, c'est par l'angle de de la de la mesure et l'objectif. Si on faisait une transposition directe, on pourrait se dire, bon euh on veut réduire le nombre de bugs total qu'on a dans le backlog à zéro. Mais ça c'est oublier ce qui arrive euh tous les jours, parce qu'en fait en réalité, on veut pas avoir de backlog du tout.
[00:15:28] Donc on pourrait regarder aussi le nombre de défauts qui arrivent par nombre de lignes de code produites. Bon, je pense que tout le monde ici n'est pas très euh pro euh regarder les lignes de code pour la productivité. On sait que il peut y avoir beaucoup de lignes de code pour pour des choses très petites, la défiche de configuration, même deux langages, on va pas vont pas du tout avoir la même chose. Donc cette métrique là, elle est pas c'est pas la plus intéressante, mais on voulait la mentionner parce que une plus complexe, c'est le fait de regarder les function points, c'est ce que mentionnait Woody tout à l'heure sur sur IBM.
[00:15:56] C'est le fait d'essayer de euh dans le code de savoir à peu près combien de fonctionnalités on a. Mais pour le savoir, il fallait regarder des choses assez compliquées, il y a ça avec des formulaires et cetera. Pour presque se dire que c'est des user story, mais bon, c'est pas tout à fait la même chose. Toi tu as une pratique différente ?
[00:16:11] Nous ce qu'on fait c'est que comme on est une boîte de service, moi ma métrique principale en tant que CTO, c'est le nombre de bugs en production divisé par le nombre de jours que je facture à mes clients parce que ça me permet si je fais x 10 en croissance, c'est a priori normal que je fasse x 10 en bug.
[00:16:24] Donc ça me permet de normaliser la métrique, on va voir tout à l'heure ce que ça donne.
[00:16:29] Si on regarde ce que dit Accelerate, en fait, eux ils regardent le le change failure rate, donc ils le prennent à l'envers, ils regardent le pourcentage de déploiement qui fail. Mais ça ça nous dit rien sur est-ce qu'on devient vraiment meilleur parce que déjà les incidents euh bon ils les décrivent pas exactement dans le bouquin euh mais a priori, c'est des incidents de prod euh pour des SRE. Euh et en fait là où là où c'est intéressant, c'est peut-être plutôt de regarder le nombre de défauts par le nombre le nombre de déploiements, qui est une métrique qui est qui va beaucoup moins jumper, tu tu utilises le mot boulien, ça va avoir tendance à faire ça le premier alors que le nombre de défauts va être beaucoup plus stable. euh qu'on pourrait se dire que l'unité de base, c'est le nombre de déploiement qu'on fait.
[00:17:11] À quoi ça ressemble les A B C D euh dans notre cas ? En fait les A B C D euh dans le dans Don't Toutsu, c'est une construction qui refait à chaque fois, c'est-à-dire qu'il y a pas une méthode pour les trouver. La seule logique derrière, c'est de se dire euh c'est de se dire euh c'est quoi la sérieuseité de ces trucs-là ? Et donc dans le dans le dev, on pourrait on pourrait par exemple pour une équipe fictive de développement d'une app voilà qui a un flux euh qui est une intégration continue, un et un déploiement continu, il y a une équipe de QA qui regarde et qui sert des des utilisateurs internes et des clients, pourrait définir les types A B C D de cette manière-là, mais on n'est pas obligé. Le premier c'est le premier type de défaut, c'est de de d'avoir d'attraper le défaut directement dans la machine du développeur, c'est un peu l'extrême programming. Ou de l'attraper dans la CI euh ou la CD si on a des tests dedans. Le euh la partie QA euh elle va vérifier les lignes de code quand elle est en aval et donc ça, ça va être plutôt des bugs de type B, des défauts de type B, pardon, parce qu'ils vont ils vont être plus difficiles, il y aura plus de friction pour euh les comprendre et les rapporter. Ensuite, une fois que le code est déployé, euh les premiers euh les utilisateurs les plus proches, ça va être les utilisateurs internes, les équipes internes opérationnelles, support et cetera. Euh, je m'en je mentionnais le le conseiller bancaire tout à l'heure. Ça c'est des bugs de type C parce que euh ça va être encore plus difficile pour eux d'exprimer en fait en quoi c'est un problème. Euh et pour qu'on vraiment on comprenne vite euh ce qui se passe. Et les les les plus compliqués, en tout cas ceux qui sont les plus euh les plus désastreux, tu mentionnais ça très bien tout à l'heure, c'est les types les types D euh pour les clients finaux qui se rendent compte qu'on a une application qui euh au pire crache, euh au mieux euh a des problèmes de performance ou euh ou est buggé.
[00:18:55] Et donc en fait, quand on fait le parallèle avec le step procédure dont je parlais tout à l'heure, ce que j'observe dans les pratiques de la plupart des équipes, c'est que les étapes sont un petit peu différentes. Généralement, il y a il y a le bug est remonté par différentes personnes. Le l'équipe généralement le product owner va qualifier la priorité de ce défaut, c'est-à-dire est-ce qu'il faut le corriger tout de suite et est-ce qu'il faut prendre des mesures long terme dessus. On priorise le fixe, on le fixe.
[00:19:24] Et parfois on fait un post-mortem ou quand quand c'est vraiment très grave et qu'on estime que il faut absolument euh expliquer au CEO pourquoi ça marche pas. Et généralement le post-mortem va aboutir vers des contre-mesures qui sont plutôt de l'ordre de l'inspection, c'est-à-dire qu'on va rajouter des tests, on va rajouter de la code review. Et ça va prendre du temps de le faire en plus. Et ça prend du temps de le faire effectivement parce que généralement j'ai essayé de faire un peu le même mapping temporel. Souvent les les trois premières étapes, elles se font au moment où le bug est rapporté. Euh par contre, le fixe du bug selon à quel point il a été identifié comme étant prioritaire, ça peut prendre plusieurs semaines, le post-mortem encore plus et alors les contre-mesures du post-mortem en général, c'est on le planifie pour Q3 quoi. Donc on n'a pas du tout la même la même intensité qui est mise dans la volonté d'éliminer les causes profondes de chaque défaut et de la vitesse à laquelle on doit le faire. expliquer au CEO pourquoi ça marche pas. Et généralement, le postmortem va aboutir vers des contre-mesures qui sont plutôt de l'ordre de l'inspection, c'est-à-dire qu'on va rajouter des tests, on va rajouter de la code review. Et ça va prendre du temps de le faire en plus.
[00:19:43] Et ça prend du temps de le faire effectivement parce que généralement, moi j'ai essayé de faire un peu le même mapping temporel, souvent les les trois premières étapes, elles se font au moment où le bug est rapporté. Par contre, le fix du bug, selon à quel point il a été identifié comme étant prioritaire, ça peut prendre plusieurs semaines. Le postmortem, encore plus. Et alors les contre-mesures du postmortem en général, c'est on le planifie pour Q3 quoi. Donc on n'a pas du tout la même la même intensité qui est mise dans la volonté d'éliminer les causes profondes de chaque défaut et de la vitesse à laquelle on doit le faire. Pour continuer les parallèles. Donc j'ai j'ai repris les différentes photos qu'on a vu tout à l'heure pour pour voir un petit peu comment comment ça se transpose chez nous. Donc le management visuel de la qualité des bugs est généralement plus réduit, c'est souvent des outils ticketing qui sont utilisés pour ça, on voit une liste de défauts. Et c'est très orienté stock, c'est-à-dire qu'on va se poser la question de comment on a moins de bugs ouverts. On va moins souvent se poser la question de comment on introduit moins de bugs les produits alors que c'est vraiment ça la volonté de de Danto Tsu. Danto Tsu. Quand on regarde les standards là, on a des pochettes numérotées où à chaque poste de travail, on a des standards clairs sur comment faire le boulot, c'est souvent moins le cas dans la tech. Et donc on on l'observe dans des bases de code où il peut y avoir du lava flow, pour ceux qui connaissent l'antipatern, c'est une zone où quand un nouveau arrive, il voit qu'il y a trois manières de faire la même chose, il sait pas sur laquelle se baser. En général, il prend pas la la plus à jour et donc ça ça crée des bases de code qui sont en difficulté. Sur les dojo, je trouve qu'on est quand même plus avancé. Dans le sens où l'extreme programming a apporté pas mal de pratiques euh qui qui nous permettent en fait de nous former et de pratiquer régulièrement, nos des katas, des euh du pair programming, de la code review. Ce que j'observe en revanche, c'est que c'est souvent moins juste à temps, c'est l'idée du dojo, c'est aussi que la personne, juste avant qu'elle ait besoin de faire un geste, qu'elle soit formée à ce geste. Là où les katas, c'est souvent en parallèle de la production, donc on se dit que c'est OK que la personne bosse et code des features. Et puis si elle a le temps de faire des katas, elle peut le faire. C'est des généralités ce que je dis mais c'est ce que j'observe en général. Sur le weak point management, c'est-à-dire cette volonté d'éliminer les bugs profonds, je trouve qu'on est aussi pas mal l'outil. Il y a il y a des outils comme comme Sentry ou des APM qui nous permettent de vraiment comprendre en profondeur des des des problèmes difficiles et récurrents. Je pense par exemple un des weak point moi que je vois dans les analyses de bug, c'est les N+1 query donc des requêtes de base de données qui sont faites de manière excessive. Qui vont causer des problèmes mémoire et donc on n'est pas mal outillé pour aller creuser ces weak point, je trouve que ça c'est pas mal. Et sur la partie 2S, c'est-à-dire comment on crée un environnement qui est maîtrisé par chaque développeur. Il y a aussi des bonnes pratiques, donc des pratiques qui permettent de d'éviter d'avoir du code mort, que ce soit facile pour un développeur de savoir où placer son code. des portails développeurs et des systèmes qui permettent de de gérer la documentation. En revanche, ce que je vois, c'est que c'est rarement mesuré aussi finement que c'est fait dans dans ce qui est décrit dans Dantotsu. cette idée de c'est OK quand ça prend moins d'une seconde et ça prend moins d'une minute. Bah souvent on va pas jusque là, on va pas se poser la question de est-ce que c'est OK que ça prenne 5 minutes à la personne de trouver qu'il faut aller dans ce dossier du code pour écrire une ligne, on va pas le mesurer. Et les rituels, donc on a effectivement, j'en parlais tout à l'heure, des daily stand-up. Généralement les daily stand-up sont quand même plus tournés autour du delivery, c'est-à-dire est-ce que j'ai réussi à livrer bah typiquement dans un mode Scrum.
[00:22:55] les points de complexité que je devrais livrer la veille. Euh c'est moins orienté qualité et c'est plus orienté autour des problèmes que l'équipe anticipe à venir dans la journée. Là où le claim AC, c'est je présente à l'équipe des problèmes que j'ai résolu la veille pour que l'apprentissage donc l'intention est un petit peu différente dans les deux.
[00:23:13] Mais assez de théorie. Parce que je pense que c'est aussi intéressant d'avoir des retours d'expérience sur ce que ça donne pour de vrai. Donc je vais te laisser la main.
[00:23:21] Merci.
[00:23:26] Donc on va parler de de ce qu'on a testé chez chez Scipio Hocus. Euh, il faut que j'arrive à comprendre comment ça comment ça marche. Faut que je vise le machin, c'est ça ? Oui. OK. Euh, donc ça c'est le logo d'Hocus. Qu'est-ce que que fait Hocus en fait ? C'est quoi c'est quoi le le métier d'Hocus ? Hocus, en fait, ils ont ils ont plusieurs produits, mais on va parler surtout de un produit qui est la marketplace, qui est le le plus gros. Euh Hocus, il il livre des photos euh de deliver photos à scale, donc il livre des photos à l'échelle. Euh, ça veut dire quoi ? Ça veut dire qu'il y a des clients comme, c'est des vrais clients, Uber Eats, Smartbox ou Necty qui ont besoin de photos de nourriture, Smartbox de lieu de voyage et Necty de d'appartement. Euh et donc ils disent OK bah non, on a besoin des photos de tel appartement à tel endroit et le point de contact sur place c'est telle personne.
[00:24:18] Euh, ce que veut le client, c'est recevoir euh le plus vite possible. Donc ils ont des SLAs, où c'est généralement c'est euh 5 à 7 jours. euh, les photos de euh, de l'endroit qu'ils ont qu'ils ont donné avec la bonne qualité, donc ils donnent un certain nombre de guidelines qui sont assez différents. Je veux avoir, je sais pas, je suis Necty, je veux avoir un truc bien éclairé, euh je veux que ce soit propre, qu'il y ait pas de gens sur la photo et cetera.
[00:24:42] De l'intérieur, ça ressemble à quoi ? Alors de manière simplifiée, le le client, en fait, il va
[00:24:47] quand il est branché dessus, il va faire appel à la à la pays web, ou alors ils vont avoir un petit front pour pouvoir le faire.
[00:24:54] Euh, dedans, ils vont pouvoir faire du coup commander des photos. Ça passe euh, il y a tout un flux à l'intérieur. Euh, donc il y a il y a une application back office où la l'équipe cognité va essayer de trouver un photographe. Parfois c'est automatique. Le photographe va avoir une app pour pouvoir euh pour pouvoir avoir toutes les informations dont il a besoin, ou il a besoin pour aller euh pour aller prendre la photo. Euh, donc le photographe remet la photo euh dans la plateforme, ça passe au niveau d'une petite opération. qui va, qui va regarder euh la qualité de la photo, dire c'est bon, elle est OK, ou la refuser, ou du groupe de photos. Ils vont envoyer ça à un prestataire qui va faire la retouche. Quand ils ont terminé la retouche, ils renvoient sur l'API, c'est retourné au client, tout ça le plus vite possible. Le problème, euh, un des problèmes, parce qu'il y en avait plein partout, un des problèmes principaux, c'est que euh le l'équipe d'opération, elle est euh déjà, elle est à la fin euh du flux. Donc il y a plein de problèmes de de lead time, parce que dès que ça prend plus d'une journée ou deux jours, ça y est, on a cassé le SLA. Et 35 % de leur charge de travail, en fait, il a il a ils arrivaient à la lier à des bugs. Je suis allé voir pour vérifier et effectivement, c'était bien le cas. Euh, Hocus c'est une entreprise de 50 80 personnes, une équipe de d'engineering de de 25 personnes entre des products et des et des tech pour vous donner une idée de l'ordre de grandeur. Et donc on a quand je suis arrivé, donc c'était c'était euh mi-mai pour donc les cofondateurs m'a demandé de de regarder la qualité et de mettre une culture de qualité donc c'était pas très bien défini. Donc j'ai regardé le truc et euh le premier challenge, c'était de de réduire le stock de bug, il y avait un stock de bug. Euh, donc là quand quand je vais dire bug, c'est défaut de type C ou D. C'est-à-dire remonter soit par par des équipes en interne, soit par des clients euh qui généralement passent par des équipes en interne pour les remonter. Ils sont aussi, bon, il y a plein de chemins possibles. Mais donc c'est C ou D par rapport à ce qu'on a dit tout à l'heure. Le premier challenge donc, c'était euh le fait de réduire le stock. Quand je suis arrivé, il y avait un stock de 50 300 bugs, là vous voyez en fait en rouge foncé, c'est les nouveaux par jour. Et en fait ça fluctue parce que ils résolvent des bugs tous les jours.
[00:27:09] Donc je parlais de la frustration des autres équipes euh qui voyaient en fait leur leur bug ne pas avancer. Il y avait un lead time assez important, très variable, il y a certains bugs qui prenaient euh qui prenaient pas beaucoup de temps et qui étaient fermés assez vite parce que c'était généralement pas des bugs. Euh on va voir ça. Et euh d'autres qui en fait étaient jamais fermés et qui vivaient là depuis 100 jours. Et en fait, quand on les regardait, on se disait mais est-ce qu'il est toujours intéressant ? La réponse est généralement oui. Euh, donc la méthode qui était qui était faite jusque-là, c'était euh deux choses. La première c'est la la remontée des bugs se faisait via un formulaire qui est écrit dans dans GitLab. ça c'est bien, ça marchait très bien. Euh, la deuxième c'est que le le PO est au centre, product owner est au centre euh de la machine, le product owner décide de ce que fait euh décidait en tout cas de là dans ce modèle là, de ce que faisait l'équipe au quotidien. Et donc en fait, il mettait les bugs en face de feature, il disait bah les features, elles sont importantes. Donc on va pas se focaliser sur ce bug là, on va le laisser traîner et puis généralement il finissait par traîner jusqu'à ce que la personne le reporter euh commence à se plaindre et dire quand même ça m'embête beaucoup. Est-ce que vous pouviez pas regarder ?
[00:28:21] Allez.
[00:28:25] Voilà. Donc, euh la deuxième chose, c'était euh le le fait d'être trop en mode quick fix. Ça on l'a vu avec le le process, donc c'est pas forcément que le le tech lead là qui est un peu le l'équivalent du team leader qui va regarder les bugs, ça va être chaque développeur, parce que chaque développeur a a peut le faire. Mais euh, il y a pas forcément de dogmatisme là-dessus. Euh, quand on regardait comment un un bug était fait, ça c'est un exemple de bug euh qui est vraiment arrivé. Donc il y avait une image en entrée euh prise, ça c'est une fausse image mais mais ça ressemble à ça. prise par un photographe euh de nourriture, ça passe dans le process d'API et en fait le but c'est de générer des miniatures pour que le client puisse déjà présélectionner des trucs. Le client, on lui livre aussi les miniatures. Et donc la miniature, elle était elle était blanchie quand en bas. Alors qu'en fait elle devait être bah la miniature de la première image. Euh qu'est-ce qui se passe euh en fait derrière ? C'est que euh quand le développeur regarde, il se rend compte que la photo en entrée avait pas le bon euh profil de couleur. Avec avec des des guillemets. le bon profil de couleur. C'était un profil de couleur un peu bizarre, on a regardé quand même euh ensemble aussi mais euh mais bon voilà. Et donc à l'époque en fait, il avait euh parce que je suis arrivé après, j'ai regardé cet exemple là en particulier qui était qui était avant. Euh, il a répondu ça, ça c'est un vrai enfin c'est le copie-colle, j'ai copié-collé ce qu'il avait fait, j'ai pris une capture d'écran. Dis après investigation, on a vu que la le problème venait des versions éditées. En fait, vous utilisez le profil SRGB de couleur. Euh mais en fait, il faut utiliser le profil SRGB IC et cetera. Euh donc du coup Bien sûr, le client le savait et c'est juste qu'il était il est méchant quoi. Bah c'est pas exactement le client, en fait, c'est c'est le prestataire externe qui essayait, donc le prestataire, il a quand même un peu le de métier, mais euh de là à se dire bah j'utilise du IGB machin. Et donc euh c'est merci pour votre temps, merci d'avoir pris le temps de remplir le formulaire. Merci pour votre temps, merci d'avoir pris le temps de remplir le formulaire, euh, envoyez-nous des meilleurs trucs. Merci, au revoir. Euh Et donc là, là, on se dit bon, on peut on peut quand même faire faire mieux. Et bon, je pense que dans la salle, vous avez déjà vu des bugs qui étaient résolus comme ça, où le développeur répond un truc où c'est bah, arrêtez de nous envoyer de la de la merde et ça se passera mieux quoi.
[00:30:35] Désolé pour euh les oreilles sensibles. Donc euh, donc le le premier truc, euh c'est euh, on a commencé le 1er juin.
[00:30:45] J'ai un peu j'ai un peu vu tout le monde et cetera et donc donc j'ai proposé un une nouvelle manière de manager les bugs, donc ça c'est littéralement le document que j'ai écrit. Euh pour dire que la qualité c'est important, plus que tout. Euh que on veut réduire le stock à zéro et euh comment on va le faire. Et que du coup le euh tech lead. Donc ça c'était ah oui, j'ai j'ai dit ça, j'ai dit aussi que j'avais passé 40 % de mon temps.
[00:31:10] à le faire avec eux, euh ce que j'ai fait le temps que ça roule donc ça a pris euh 3 4 mois. Le ça on l'a gardé, ça ça marchait très bien donc on a on a gardé le même flux, on a un petit peu retravaillé le formulaire un peu après. Mais ça ça venait de de des équipes. Euh la deuxième chose qu'on a changé, c'est de changer l'intention.
[00:31:28] Donc le la personne qui qui reporte le bug, maintenant en fait, c'est traité directement par le par le tech lead. euh où l'équipe en fait parfois sur des trucs un peu plus où il a pas forcément besoin d'intervenir et le tech lead en plus généralement on a une équipe front, une équipe back. Donc sur pas mal de bugs, ils doivent se parler très vite pour pouvoir pour pouvoir agir. Et beaucoup de bugs qui traînaient parce qu'il s'étaient pas parlé.
[00:31:52] Euh deuxièmement, on a fait du coup une équipe qualité avec euh tous les tech lead des équipes. Engineering manager et des contributeurs individuels qui étaient qui étaient dans la boîte et qui étaient intéressés par la qualité, donc c'est les gens moteurs en fait qui étaient attirés par ce truc là je les ai fait venir. Et donc du coup moi je participe aussi mon but étant de faire monter parce que vu que c'est une mission de CTO par intérim, elle a une fin, donc je voulais aussi que ça ça ça perdure. Et donc c'était le but c'est de former l'engineering manager à prendre ça ensuite pour la suite. Troisième chose du coup, c'est le fait de faire des sessions hebdo autour des QRC. Alors c'est l'équivalent de ce qu'ils faisaient en claim AC. Euh donc là j'ai je l'ai fait déjà au niveau hebdo. Euh, au quotidien c'était trop compliqué pour le moment donc bien commencer quelque part. Pour aussi partager la manière de résoudre des problèmes. Et ces sessions sont faites avec l'équipe technique, l'équipe produit, tous les tous les team lead. euh des autres équipes d'Hocus sont invités aussi, il y a un certain qui viennent parce que ça les intéresse. Euh et qui continuent de venir. Et les deux cofondateurs euh qui sont là aussi, qui sont là d'ailleurs tous les deux 80 % du temps. Euh et c'est pas 50 % l'un, 50 % l'autre, généralement on est tous les deux 80 %.
[00:33:07] Euh assez réunions là. Et donc tout le monde regarde des exemples. Donc là, on va en voir un. Euh, ça c'est une c'est un bon, c'est des des captures d'écran, on les enregistre, il y a beaucoup de gens, en fait, quasiment toute l'équipe technique est à distance euh chez Hocus. Ça ça c'est Remy, c'est un contributeur individuel qui présente comment il a il a regardé des requêtes réseau euh le nombre de bail des requêtes réseau pour essayer de déboguer un problème de d'upload de fichiers sur AWS. Euh, ça c'est Olivier qui est team leader front euh qui présente différentes choses qu'il a essayé sur des sur des causes. Euh, ça c'est euh,
[00:33:45] Je me disais que j'aurais un trou de mémoire débile sur un des gens sur un des techs.
[00:33:49] Vous avez écrit.
[00:33:51] Hein ? Ah oui, c'est Edwin, pardon. Donc c'est Edwin, alors Edwin, il fait pas partie des des équipes techniques. Edwin, il est il est team leader d'une de l'équipe des opérations et en fait, il est il est intéressé par pas mal de problèmes qui sont qui sont là. Et donc euh donc là il discutait un petit peu de de problème de de connexion avec le l'éditeur de photos. Et euh Lionel, qui arrive. Ah.
[00:34:15] Et Lionel qui présentait, alors lui il présentait un schéma de il faisait du weak point management. Donc il regardait en fait tous les problèmes potentiels justement avec le même éditeur de de photos. Donc à droite c'est c'est moi qui qui qui sourit béatement et euh le cofondateur d'Hocus Julien.
[00:34:34] Allez. Donc, pour regarder un des QRC qui a été fait par par Remy, un autre Remy. Euh, Remy lui, il s'intéresse à la à la performance de la pays. Il s'intéresse à la performance. Et en fait, ils sont mis des critères de performance euh sur des end points, mais non seulement il y a ça, mais aussi ils avaient des un un end point d'API. euh qui envoyait des timeout. Le problème c'est que c'est le end point d'invoicing. Donc qui sert à payer les photographes euh à la fin du mois. Et ce ce end point arrêtait pas de de casser. Donc ça c'est un bug de type C, c'est celui qui a attrapé dans la machine.
[00:35:08] sur la prod et qu'on va essayer de résoudre.
[00:35:12] Euh, quand il quand il revient, du coup, il est il est très lent. Je vais le faire assez rapidement parce que je vois qu'il est je vois qu'il est euh il est 8. Euh, donc il il évalue le business impact rapidement. Il regarde en fait aussi après à quoi ressemble exactement le bug. Donc il nous montre un graphe en dessous qui est intéressant. qui est en abscisse le nombre de requêtes et la couleur c'est rouge-orange en fonction de si la requête réseau a pris trop de temps. Et orange, par exemple, c'est les requêtes qui ont pris plus de 6 secondes, donc vous imaginez l'utilisateur en face.
[00:35:39] Euh, et donc ensuite, il explique ce qu'il a fait pour pour corriger. Donc avec du code, on n'a pas peur de montrer du code dans ces dans ces sessions là. Euh, et ensuite il a il montre à la fin ce que ça a donné sa correction. C'est que le le graphe qui est tout en bas là à gauche, celui qui monte du du orange, du orange, du orange et ensuite un gros pic de jaune, en fait, ça veut dire quoi ? Ça veut dire que tout à la fin là, c'était le la fin du mois à droite, le pic, c'est en fait le nombre de requêtes euh au end point d'invoicing et ils sont jaunes parce qu'il a résolu le problème et qu'elles prennent toutes moins d'une demi seconde.
[00:36:12] Derrière, euh il explique aussi toute la logique, donc euh de ce qu'il a fait pour pouvoir euh pour pouvoir avouer ce qui était le problème. Donc il a essayé de voir comment c'était introduit, quel développeur avait fait ça. Bon c'était trop trop vieux donc il a pas il a pas beaucoup creusé. Euh, il a aussi regardé euh quel quelles métriques on pouvait se mettre, quel quel's alerting on pouvait on pouvait mettre en place. Euh, il a vu aussi qu'il y avait des problèmes, donc tu as parlé tout à l'heure des N+1 query en SQL. Ou alors des problèmes d'optimisation des algorithmes. Et euh, justement en fait, à cette réunion là, euh le cofondateur et CEO a dit mais en fait euh, est-ce que tu t'es posé la question de la formation des gens ? Euh parce qu'en fait euh il y a des choses sur les algos. Et donc il a dit bah non, j'y ai pas pensé et euh deux jours après, il revenait vers moi en me disant ah j'ai je vais faire une formation de tout le monde. Donc ça sert aussi à ça, on n'a pas besoin de faire les trucs parfaits, on a surtout besoin de faire en sorte que les gens pensent à toutes les choses intéressantes. Et donc on a changé de manière de travailler donc en fait chaque résultat en fait de chaque innovation que chacun apporte là-dessus sur l'entraînement donc ça c'est le l'angle human. Sur les méthodes, comment est-ce qu'on va changer notre manière de travailler, comment est-ce qu'on change la manière dont nos machines sont configurées ? Comment on change les matériaux donc les informations en entrée. Euh tout ça, en fait, on va travailler dessus en continue donc avec 35 QRC. On a on a changé en 4 mois euh la manière dont on travaillait de manière assez assez radicale. Et euh je vais le faire assez rapidement. En fait le d'abord on on a on a essayé d'identifier les bugs qu'on pouvait fermer rapidement. En fait, on a s'est assez rapidement heurté un mur. Euh, l'équipe a été prise pendant tout le mois de d'août sur un un projet hyper important. Euh donc euh ça a commencé à slip back. Il y avait il y avait des vacances en plus. On a récupéré le le truc en en septembre pour pouvoir remettre remettre tout ça. Maintenant, on est passé de 50 à 12.
[00:38:03] 60 à 12.
[00:38:07] Donc il y a plusieurs difficultés, la première c'est de le faire de bout en bout, the way. Euh donc que que chaque développeur puisse vraiment comprendre le problème de la personne en face et qu'il le résolve vraiment. La deuxième, c'est que c'est euh c'est vraiment les gens les plus importants. Donc on a il y a des choses où les développeurs discutaient par commentaire GitLab. Euh, et cetera et ça prenait un temps de de fou. Donc ils ont beaucoup plus ils sont sortis un peu de leur coquille. Euh, garder le rythme, donc en en soutenant l'engineering manager, en soutenant l'effort de de résolution des euh des bugs. Et euh toujours essayer euh d'être plus rapide dans le fait de le résoudre.
[00:38:49] Donc ça montre des résultats, on a de moins en moins de bugs qui arrivent. Donc ça c'est par quarter, le Q4 il est pas terminé mais déjà on voit que au prorata, on en a deux fois moins. Et on arrive de plus en plus à le régler en un jour ouvré. Alors c'est réglé, c'est pas le la boucle en 8 étapes complète, c'est juste au moins déjà le bug est plus impactant. Euh et qu'on essaie aussi après de de s'améliorer sur la résolution globale.
[00:39:17] Je te passe la main.
[00:39:18] Merci. Je vais partager mon retour d'expérience. Donc qui c'est intéressant parce qu'on a pu suivre nos nos expériences euh en parallèle, on n'a pas fait exactement la même chose. Et donc euh donc Scipio, on est on est une boîte de service, donc on accompagne des clients. Et donc le client un peu pionnier sur lequel j'ai testé Danto Tsu, c'est le digital de BPI France. Donc en 2019, on avait une équipe donc qui sont tous à cette table, j'y étais pas d'ailleurs à ce repas, dommage.
[00:39:45] Et euh 3 ans après en fait, on a eu un scale quand même assez rapide. Donc on a autour de 100 personnes impliquées qui travaillent aujourd'hui donc des développeurs, des PO, toutes sortes de profils sur le digital. Donc là je crois que j'y étais par contre, oui, je suis en bas à gauche là. Et euh en fait ce scale, il s'est fait aussi parce que le client était très content de ce qu'on faisait, on a eu des belles réussites, on a lancé le le prêt garanti par l'État en 5 jours. On a on a des très bons NPS sur les applications qu'on développe avec eux, les utilisateurs finaux sont plutôt contents de ce qu'on fait. C'est un NPS de 67. Et puis on a pu expérimenter pas mal de trucs, je crois qu'il y a eu des talks dessus sur la loi de Conway, on a on a découplé l'architecture, on a fait du team topologie, on a fait plein de trucs cool. En revanche, euh, le scale nous a rattrapé. Donc là vous voyez, c'était l'année dernière, euh les bugs en production sur ce client donc ont quand même augmenté de manière significative. Jusqu'à arriver à un point où ça devenait un problème prioritaire du point de vue du client. Donc là, j'ai mis une quote que j'ai traduit en anglais. Mais vous avez pas envie d'avoir cette quote là de votre client, je pense si vous avez déjà eu des quotes similaires. Euh parce qu'en fait ça ça commençait à nuire à la réputation du digital de BPI France vis-à-vis des métiers, vis-à-vis des utilisateurs et cetera. Donc on commençait à à poser un véritable problème. Donc j'ai j'ai décidé de réagir. Euh et ça s'est fait un petit peu par hasard, je suis tombé sur une vidéo de de Michael Balet que vous connaissez peut-être pour ceux qui connaissent le Lin. Euh qui parlait du Lin dans la fonction qualité. Donc quel était le rôle de de de de la fonction QA en fait dans une boîte. Et donc il y avait ce petit bouquin en bas à droite, donc ça ça m'a parlé l'approche radicale de qualité. Donc je l'ai acheté, je l'ai lu dans un endroit un peu insolite puisque j'étais en train de faire un trek au Maroc quand j'ai lu ça, je pense je suis le seul à avoir lu un bouquin de Lin dans l'Atlas. D'ailleurs je savais pas que ce c'était qu'un trek donc c'était d'autant plus difficile. Euh, je pensais qu'il allait avoir plus de de chameau et de et de voiture, bref. Et donc je rentre de vacances super excité à l'idée de de de commencer à implémenter tous les trucs que j'ai lu dans le bouquin où ça parle de fuite d'huile, ça parle de voiture, ça parle de trucs très différents, je me suis dit comment ça s'applique chez nous. Donc j'ai fait du management visuel physique d'abord. Donc on voit là les quatre feuilles du haut, c'est ça permettait aux équipes de noter leur bug A B C D. Et les feuilles du bas, ça permettait aux équipes de noter des analyses assez synthétiques. Où on avait même le bout de code qui était imprimé et donc l'équipe expliquait quelle était la cause qui a permis au bug d'apparaître et quelle était la cause du fait qu'on l'ai détecté aussi tardivement.
[00:42:15] J'avais un exemple de QRC mais comme on n'a pas beaucoup de temps et que Flavien t'a déjà décrit, je je vais le passer. Mais donc dans l'idée, on avait un format qui était assez complet où on avait le problème, l'impact du défaut. On avait trouvé la user story qui avait introduit le bug. On avait trouvé le bout de code qui avait introduit le bug. Euh on avait détaillé quelles étapes notamment de review et de test avaient amené à son apparition. Et puis on avait trouvé des euh des erreurs, c'est-à-dire quelles étaient les erreurs qui avaient amené à l'apparition de ce bug pour en déduire en fait des des causes racines de l'apparition de ce bug. Donc à gauche c'est des causes euh pourquoi le bug est apparu. Donc là par exemple on savait pas correctement comment stocker et et se balancer des montants, on avait un fournisseur qui nous envoyait un montant sous forme de chaîne de caractère en en centaines de millions d'euros et ça causé un bug. Et à droite, euh, qu'est-ce qui fait que on l'a détecté aussi tardivement ? Donc là, on s'intéresse plutôt au test, euh à la review et cetera.
[00:43:11] Et donc ça ça a eu des effets positifs, ça a créé vraiment une culture de la qualité beaucoup plus forte dans la boîte. Euh on est nombreux à avoir construit un système qui nous permet de monitorer les bugs à l'échelle de la boîte. Je voyais dans les discussions que j'avais avec les équipes qu'on était beaucoup plus dans des discussions poussées sur la qualité, sur le craft, euh plutôt que de dire j'ai pas fait gaffe, c'était j'ai mal appliqué le refactoring de Martin Fowler. c'était j'ai mal appliqué le refactoring de Martin Fowler et il me il me donnait le nom du refactoring, donc des discussions beaucoup plus poussées.
[00:43:35] Mais en revanche, j'ai eu quand même des problèmes, c'est-à-dire que l'approche du du du management visuel physique n'était pas très adaptée à des équipes qui étaient partiellement remote. Je me rends compte que c'était plus dur de le faire avec des équipes qui avaient des problèmes importants de stock comme tu en parlais tout à l'heure dans ton cas chez Ocus. Je me rendais compte qu'il y avait parfois des bugs qui avaient été introduits il y a 2 ans et que du coup le dev était même plus là donc pour comprendre pourquoi il avait fait l'erreur, c'était pas très intéressant en fait. Je voyais que ça leur prenait du temps. Donc le truc que je vous ai montré avant, ça prenait pour quelqu'un qui sait faire ce type d'analyse, ça prend quand même 2 heures. Donc quand tu dois le faire pour tous les bugs en fait, à un moment, c'est pas compatible avec l'emploi du temps d'un tech lead ou d'un dev.
[00:44:11] Et puis ça ça allait souvent dans des sujets qui étaient pas vraiment des sujets de maîtrise technique, c'était souvent des sujets de on est pressurisé par le delivery ou bien c'est l'autre équipe qui a mal fait donc on était beaucoup sur des sujets de collaboration ou de conditions. Ce qui sont ce qui évidemment pas ignoré mais moi je voulais aussi susciter des apprentissages techniques par cette activité là. Et puis j'étais aussi un facteur limitant parce que j'arrivais pas à passer suffisamment de temps avec l'ensemble des équipes et donc je me rendais compte que j'arrivais pas. Et donc on a on a conçu un nouveau système euh pour répondre à ces contre-mesures. Donc premier truc, c'est qu'on a on a un format beaucoup plus léger qui tient sur une slide en fait où on voit la description du défaut du point de vue de l'utilisateur, on a le code défectueux, on a une cause d'introduction du défaut. qui est une cause qui que je veux être autour d'un geste technique. Donc là c'était un sujet assez pointu de sérialisation quand on converti du Java en Kotlin et une cause de non-détection. Et donc avec des contre-mesures locales à l'équipe.
[00:45:14] J'ai pris aussi un projet pilote. Donc Thibo qui a fait qui était tech lead d'une équipe avec qui on a fait des KRC tous les jours à 18h, notamment avec le CTO du groupe et moi-même. Ça l'a tellement motivé qu'il a fait une conf au Human Tox qui ressemble à celle d'aujourd'hui mais au niveau de son équipe. Et ça a eu un impact super fort. Donc ça c'est les bugs en prod in, donc les bugs détectés et donc en 3 mois, on a quand même une diminution de 80 % des bugs qui étaient introduits par l'équipe. Donc ça a vraiment eu des des effets très forts sur cette équipe pilote.
[00:45:44] En revanche, au niveau de Scipio, il y avait tout à l'heure une une conférence sur qu'est-ce qui est un qu'est-ce qui est du bruit versus qu'est-ce qui est une vraie cause. Pour l'instant, je pense qu'on est plus au stade de bruit, ce que je vise c'est de diviser de réduire de 88 % en 3 ans. Donc là, j'ai réussi en septembre mais je vois que juillet a été très compliqué. Je vois qu'il y a plein de effectivement de bruit comme comme c'était dit dans la conférence tout à l'heure, notamment à quel point l'équipe est rigoureuse sur le fait de noter tous les bugs. Je constate que quand une équipe lance un chantier de bug, il y a beaucoup plus de recettes, beaucoup plus de QA, beaucoup plus de rigueur et donc là ça ça affecte très fortement ma perf. Donc je me rends compte que je vais être obligé de faire ce que j'ai fait avec cette équipe pilote. quand même équipe par équipe pour que ça scale.
[00:46:24] Dernier point peut-être qui a été quand même vraiment utile. Moi en tant que CTO, ça m'a permis de voir quelles étaient les problèmes types, les vraiment les weak point des équipes. Donc on a identifié euh huit gestes, on va se donner max 10 euh pour construire vraiment une académie de formation avec une boîte qui s'appelle I know, Regis qui en est le fondateur a fait un talk hier, de dire quels sont les les gestes clés qu'un développeur doit maîtriser pour ne pas introduire de bugs. Et on veut pas en avoir plus de 10, on veut que ce soit vraiment les fondamentaux et sur ces gestes là, on a créé des standards, des cours et même des simulateurs. Donc où la personne peut s'entraîner à relire des refactoring par exemple pour dire est-ce que c'est un bon refactoring ou pas avec les points de contrôle de Martin Fowler. Donc c'est ça nous permet de bien investir sur la formation.
[00:47:07] Conclusion.
[00:47:09] Conclusion. Euh donc le le but de la conclusion, c'est que vous repartiez avec euh.
[00:47:14] trois quatre points clés sur lequel nous on s'est mis d'accord euh qui qui sur lequel nos expériences qui sont assez diversifiées, en fait euh on n'a pas du tout fait les mêmes choses et c'est pour ça qu'on est très complémentaire, je pense. La première chose, c'est le le le buy du top management. C'est que le top management monte de l'intérêt, viennent vraiment s'intéresser, demander pourquoi, peut-être challenger un petit peu aussi les développeurs, ça recrée aussi un lien. euh entre les entre les cofondateurs et les développeurs qui avec le scale euh surtout dans dans des contextes de start-up a tendance à à disparaître. La dernière la deuxième chose, c'est l'entraînement à la résolution de problème. La résolution de problème, c'est très dur. Déjà rien que faire un QRC en 2 heures, c'est euh il y a peu de gens qui arrivent parce que euh parce qu'en fait, il faut penser à tout. Donc il faut avoir pratiqué et vraiment penser à tout tous ces petits trucs là et avoir un travail de détective. Ça prend beaucoup de de de coaching euh de le faire, de pratique et de partage aussi aux autres équipes.
[00:48:18] Et deux idées qui ont été clés clés chez moi, c'est se focaliser sur un apprentissage technique plutôt que de balayer tout un arbre de cause, parce que chaque bug, il y a en général 10 causes différentes au moins qui apparaissent.
[00:48:30] Donc se focaliser sur une qui permet au développeur de progresser techniquement. Parce que j'ai constaté que ça crée plus d'intérêt chez eux quand ils commençaient par des bugs où ils apprennent des choses sur leur métier.
[00:48:42] Et puis le dernier point qui est important et qui est vraiment le début de de Danto Tsu, c'est de de vraiment mesurer. Donc ça a été compliqué, ça m'a pris quand même plusieurs mois d'avoir une mesure de bug au niveau de Scipio, ça prend du temps. Euh il faut le faire et il faut se fixer des objectifs pour être capable de créer une énergie et un momentum autour de ces chantiers de Danto Tsu et donc c'est vraiment pour ça que c'est la première étape.
[00:49:02] On vous on vous a mis là en synthèse et on sera ravi de les partager avec vous nos nos templates de KRC qui sont un peu différents. Donc ça c'est celui d'Hocus qui est ici. Euh, je je rendrai dispo les slides et vous pouvez nous les demander aussi.
[00:49:13] Ça reste sur nos notions, les deux.
[00:49:15] Exactement, c'est du Notion pour les deux, euh, et et le mien que j'ai montré tout à l'heure, donc vous pourrez tester les formats qui vous conviennent et peut-être les adapter par rapport à votre contexte.
[00:49:26] Voilà pour notre talk. Merci beaucoup euh aux organisateurs, aux sponsors et au public.
[00:49:32] Oui, merci au public.
[00:49:34] Et euh,

Transcription