2 CTOs, 2 stratégies de qualité, 1 seule recette !

0:00 On a vu, Alexis nous a donné beaucoup de clarté en fait sur GitHub. Il y a peut-être un autre sujet sur lequel vous avez envie d'être éclairé. C'est quand on décide, quand on est dans une période de scale, est-ce qu'on arrive en fait à combiner tous les enjeux et surtout à embarquer une stratégie de qualité? Est-ce que ça se fait avec l'économie d'autres sujets? Je vous en prie, je vous en prie, installez-vous tranquillement avant qu'on sauve nos prochains. Le premier rang est pas mal, franchement, on voit vachement bien. Je vous laisse vous installer. On est tous au point, on est bien? Je continue? Ouais, super. Donc cet autre sujet, c'est comment on applique une stratégie de qualité à grande échelle. Ce n'est pas toujours simple. Et surtout, ça peut avoir parfois des airs de long parcours du combattant. Je pense que certains d'entre vous connaissent ces moments-là. Tout ça en gardant une exigence pour avoir des produits de qualité. Et nos deux prochains speakers se sont penchés largement sur cette question il y a plus d'un an maintenant. Ils vont nous raconter le chemin et surtout la manière dont ils ont pu embarquer leurs comex, leurs équipes sur ces sujets-là.

1:02 Leur objectif, c'est de vous donner envie, vous le savez ici, c'est le partage, on l'a dit tout à l'heure, vous donner aussi envie de répliquer ces bonnes pratiques. Alors je vous demande d'accueillir Aurore Malherbes, qui est cofondatrice et CTO de Padok, et Thomas Walter, qui est cofondateur et CTO de Hokla. Le floor est à vous. Vous n'avez pas de zapette? Exactement. Je vous laisse officier tranquillement et à tout à l'heure. Pardon, on fait ça. A tout à l'heure. Merci Elsa. Bonjour à tous. On va effectivement vous parler de qualité pendant les 25 prochaines minutes et puis on vous laissera poser toutes vos questions ensuite. Je me présente, je m'appelle Aurore Malherbes, je suis donc CTO cofondatrice de Padok, une start-up du groupe Théodo. On est plus de 70 et on conçoit, on construit, on sécurise et on opère des infrastructures cloud. Je suis avec Thomas, CTO et cofondateur d'Hokla.

2:03 Hokla, ils accompagnent des entreprises dans le développement de dispositifs médicaux logiciels et plus largement sur des projets de santé. Ils sont une trentaine aujourd'hui. Mais on n'est pas venu vous parler de nous, on est venu vous raconter des histoires. Pour ceux qui ont assisté au talk que j'ai fait l'année dernière en remote depuis vos canapés ou vos chaises de bureau, Vous savez que j'aime bien raconter des histoires, donc on va continuer sur cette manière de faire cette année. Du coup, Père Castor, comment il fait pour raconter une histoire? Rapidement, on reprend les cours de français. Il y a une situation initiale. À un moment, il y a un élément déclencheur. Il se passe quelque chose. Il y a plein de péripéties. C'est dur. Il y a des nouveaux personnages qui arrivent. On a l'impression qu'on régresse. Et puis, en fait, on continue. Ça se finit. toujours bien les histoires parce que sinon c'est pas drôle mais surtout ce qui vous intéressera c'est qu'est ce qu'on a appris de ces histoires là et du coup je vais laisser thomas vous raconter l'histoire de la qualité chez au clair merci Aurore alors mon histoire elle commence avec le début d'au clair donc on est on est 5 6 il faut imaginer on est dans l'open space et je suis avec xavier xavier qui vient d'arriver chez nous en tant que développeur

3:14 Et il travaille sur une application mobile. Et là, j'avais une heure à tuer, donc je lui ai dit, Xavier, tiens, on va faire un peu de pair programming ensemble. Explique-moi ce que tu dois faire. Et Xavier me dit, j'ai un ticket assez facile à faire, je centre un texte sur un écran. C'est parti. Après, il me fait un aveu. Je suis un peu rouillé, je ne sais plus exactement comment on fait. Alors, je vais demander à mon ami préféré. Alors à l'époque c'était encore Stack Overflow et pas ChatGPT. Comment on fait ça? Et donc il regarde et puis il trouve une première solution. Tu vois, ah bah oui c'est vrai, il faut utiliser Text Align Center. Bon bah je copie-colle, je mets ça dans mon éditeur de texte et j'appuie sur Run et je regarde. Merde, ça ne marche pas. Non, mais en fait, c'est vrai, ça ne marche pas. Il faut que j'utilise Margin, Auto. Voilà, en fait, oui, c'est ça qu'il faut faire. Pareil, je copie-colle, j'appuie sur Run, je lance. Ça ne marche pas. Et vous me voyez venir, on continue comme ça, on continue comme ça. Et il se passe 45 minutes à faire... Des allers-retours entre l'écran, l'éditeur de texte, le téléphone qui tourne à côté.

4:17 Et puis moi, je suis un peu embêté. Parce que j'avais qu'une heure devant moi, je vois le temps qui passe. Et je dis à Xavier, écoute, arrête-toi là, on n'a plus que 15 minutes. Ce qu'on va faire, c'est qu'on va se lancer un petit défi. Tu n'as droit plus qu'à un seul essai. Tu peux appuyer sur« Run» une seule fois et ça doit marcher. Donc Xavier réfléchit, il me dit« bon attends, si j'ai plus qu'un essai, je prends un peu le temps». Donc il prend une feuille, un papier de crayon, il gribouille, il va sur la documentation de React Native, et au bout d'un moment, il écrit son code. Et avant d'appuyer sur« Run», je lui pose la question« t'es sûr, ça va marcher? »« Oui, ça va marcher. T'es sûr? »« Oui. »« Ok. » C'est parti, il appuie sur« Run». Ça marche. En fait, ce n'est pas si facile que ça finalement. Et ça, ça m'a donné une idée. Mais en fait, on a passé 45 minutes à copier-coller du code et ça ne marchait pas. Et en réfléchissant avant de coder, ça paraît con, mais si on commençait à réfléchir,

5:20 On a réussi à faire des belles choses. Et en fait, on a finalement fait deux belles choses. La première, c'est qu'on a fait de la qualité. Le code était bien pensé. On a mis du temps. On était sûr de ce qu'on voulait faire. Et en fait, on a réduit aussi le lead time. On a passé 15 minutes à faire le ticket. Si on avait fait ça dès le début, moi, j'aurais gagné 45 minutes pour aller prendre un café. Et là j'ai eu une petite idée, je me suis dit mais attends c'est vachement intéressant, moi aussi j'ai envie de tester ça. Et là on s'est, j'ai dit à Xavier, bon, tu sais quoi tu vas continuer à faire ça, chaque ticket tu vas commencer et tu vas te dire tu as droit à un seul essai. Et puis Maxime et moi on va jouer aussi. Et on va essayer de faire bien du premier coup. Right? The first time. Donc on avait un grand tableau blanc dans l'open space et on a écrit nos noms. Et le jeu c'était de rajouter un petit bâton quand on arrivait à faire Bright the first time. Donc au début c'était vide, au bout d'une semaine, Maximis Lev dit c'est bon j'ai réussi, il fait un trait, il est content, on va voir avec lui, vas-y comment t'as fait, montre-nous.

6:22 Et puis petit à petit on noircit un petit peu le tableau. J'avance un petit peu, petite ellipse narrative. Dans mon histoire, on passe d'un jeu à trois joueurs à un jeu vraiment multiplayer. On passe un cas joueur. Qu'est-ce que ça change? On va essayer d'adapter ça pour un peu tout le monde. La première chose à faire, c'est d'adapter le jeu pour passer à l'échelle. Le tableau blanc, c'était sympa, mais ça ne marche pas pour autant de joueurs. Donc on est passé sur Notion, on a fait une base de données avec chaque ticket, on renseignait le nombre d'essais qu'on faisait. Et donc pour chaque ligne, on a soit un essai, on a fait le first time, j'ai une petite étoile, ou alors je n'ai pas fait un essai, j'en ai fait plus qu'un, et dans ce cas-là, j'ai un défaut, donc j'ai une petite croix. Ça, ça va être intéressant, je vais y revenir après. Mais en tout cas, à partir de là, avec Xavier, ce qu'on commençait à faire, c'était regarder les étoiles, mais aussi les petites croix. On a rajouté un petit bot sur Slack qui s'appelle Ward, je vous expliquerai plus tard pourquoi Ward, et qui mettait un message quand quelqu'un faisait un blague de first time, ça permettait de célébrer, les gens réagissent de la manière que Maxime faisait un trait sur le tableau.

7:35 Alors, il y a une autre chose qu'on a fait. Donc effectivement, on a aussi des défauts et on se pose la question, qu'est-ce qu'on fait quand on a des défauts? Ça peut être intéressant d'y réfléchir. L'autre chose qu'on a mis en place, c'est un framework qui s'appelle Dantotsu. Alors la meilleure manière que j'ai de vous expliquer Dantotsu, c'est de vous inviter à aller au talk de Woody et Reynald juste après. Mais un élément important de Dantutu, c'est de dire qu'on va classifier les défauts. Donc tous les bugs qu'on rencontre en fonction du moment où on le détecte. Donc le défaut qu'on connaît tous, c'est le bug en production, c'est le défaut D, il arrive en fin de chaîne de production. Et moi, ce que j'avais comme défaut, c'est des défauts A. C'est vraiment au niveau du poste du développeur, je code, je n'y arrive pas du premier coup, j'ai un défaut. Et là, on a commencé à mesurer ça et puis on voit des choses intéressantes arriver. C'est qu'on a évidemment beaucoup plus de défauts A que de défauts D. Parce que là, on est assez content, parce que si on aurait un vrai problème. Et on s'est rendu compte que c'était beaucoup plus intéressant d'avoir des défauts que des défauts D.

8:36 Un défaut D, c'est un bug en production qui a un impact significatif sur vos utilisateurs, sur votre réputation. Mais à débuguer, c'est super dur. Il faut regarder des logs de serveurs, il faut se connecter en SSH. On va passer une journée juste à trouver comment corriger le bug. Et puis on va passer une autre journée à comprendre pourquoi le développeur qui a développé ça il y a six mois, qui n'est plus là, a écrit cette ligne de code qui ne marche pas. Alors que le défaut A, le développeur vient de la faire, donc très bien, il corrige son défaut et puis hop, il passe 15 minutes à comprendre qu'est-ce qui s'est mal passé, comment il a introduit ce défaut. Et en fait, il tire de l'apprentissage beaucoup plus rapidement qu'avec un défaut D. Donc en fait, c'est un potentiel d'amélioration bien plus important que de regarder les défauts de production. Alors, pour vous donner une petite idée de qu'est-ce qu'on peut avoir comme apprentissage, je voulais vous partager un méchant bug qu'on a eu. Sur une interaction entre React, et en l'occurrence une mauvaise pratique qu'on avait sur React, et une librairie qui s'appelle React Query.

9:39 Et en regardant ce défaut, on a non seulement réussi à recoger ce défaut, vous voyez ce graphe qui n'arrive pas à se générer, une espèce de boucle infinie, on a tiré un apprentissage qu'on a pu appliquer sur d'autres projets et qui a augmenté la performance de certaines applications jusqu'à 20%. Donc un défaut qu'on a rencontré à un moment sur un projet nous a amélioré. d'autres projets, donc vraiment la compréhension, la connaissance de Hokla. Voilà, c'était mon histoire. Aurore, je te laisse la parole pour nous expliquer la tienne et je vous mets au défi de regarder quelles sont les similarités et les différences. Alors effectivement, moi je ne vais pas vous parler d'une histoire de centre, je vais vous parler d'une histoire de cycle. On revient dans le passé, on est à l'été 2021, on est une cinquantaine chez Padok, et je fais un peu le bilan. Ok, ça fait trois ans qu'on existe, où on en est? Globalement, ce que je me dis, c'est qu'on arrive à livrer nos projets dans le temps. On a un objectif, on a un certain nombre de semaines pour y arriver. Globalement, ça se passe bien.

10:41 On arrive aussi à vraiment écouter notre client, donc à vraiment penser produit, quelle est la valeur qu'on apporte. Et donc, c'est bien de livrer quelque chose dans les temps. C'est mieux de livrer quelque chose dans les temps qui va servir. Donc, je me dis, OK, ça, on n'est pas parfait. Je pense qu'on ne l'est jamais. Mais globalement, on est plutôt bon sur ce sujet-là. Donc, la question, c'est what's next? Qu'est-ce que je fais ensuite? Là, je fais une petite introspection. Je me dis, OK, je suis CTO. Le T de CTO, a priori, c'est quand même pour technique. Et dans ces deux gros chantiers finalement c'est un peu éloigné de la technique. Je me dis ok quand on s'intéresse à la technique on s'intéresse à quoi? On s'intéresse à la qualité. Donc bingo, j'ai trouvé mon nouveau chantier qui va m'occuper au moins le reste de l'année 2021. J'étais un peu naïve à ce moment-là mais je me dis on va s'intéresser à la qualité. Je commence par me dire, je ne sais pas ce que c'est la qualité pour tous les ingénieurs chez moi, donc je vais aller les voir et puis je vais aller faire un petit micro-trottoir.

11:42 Je vais en prendre 4-5, des jeunes, des vieux, des expérimentés, des moins expérimentés. Et puis je vais lui leur poser la question. Est-ce que tu fais de la qualité? Donc je vais les voir, je commence à avoir une discussion. Premier ingénieur, j'ai une réponse qui est« bah oui, mon client, il est satisfait, donc je fais de la qualité». Je dis rien, je continue mon petit micro-trottoir. Je vais voir une deuxième personne qui me dit« bah ma prod, elle n'a jamais craché lors d'un pic de trafic, donc oui, je pense que je fais de la qualité». Pareil, je ne dis rien, j'enchaîne, je continue. Je vais voir une autre personne qui me dit« Ah non, moi je pense que je ne fais pas de qualité parce que j'ai récupéré un code Terraform, il est architecturé n'importe comment, donc non, c'est sûr que de toute façon, je ne peux pas faire de qualité. » Et donc là, j'ai fini mon micro-trottoir, je reviens chez moi et je me dis« Ok, j'ai eu 4-5 réponses différentes. Toutes différentes de celles que moi j'aurais données. Donc globalement, j'ai plutôt envie de me jeter par la fenêtre. Alors la bonne nouvelle, c'est comme vous pouvez le voir, ça doit être au rez-de-chaussée.

12:43 Donc à part être ridicule, il ne me serait pas arrivé grand-chose. Mais surtout, je me dis, je ne vais pas me jeter par la fenêtre, de toute façon, je cherchais un petit os à ronger. Donc je me remonte les manches et je fais un plan. Puis je me dis, faire un plan, c'est facile, de toute façon, améliorer la qualité, c'est choisir un cas. Je le mesure, j'y terre dessus, comme ça j'apprends des choses, il augmente, et puis voilà, je pourrais passer à autre chose ou partir en vacances. Donc je choisis un capiel qualité, je me dis, facile, je prends le nombre de bugs en production, les fameux, les bugs D, je vais les mesurer toutes les semaines et puis on va y terrer dessus. Et puis là, on a commencé à moi me poser des questions, à me dire, ok, mais en fait c'est quoi un bug? Est-ce qu'un bug c'est une erreur 500, il n'y a plus rien qui marche? Est-ce qu'un bug c'est quand j'appuie sur mon bouton, il ne se passe rien? Ou est-ce qu'un bug c'est, en fait là, je devais avoir ce comportement-là, mais le produit ne l'a pas prévu, donc en tant qu'utilisateur, je considère que c'est un bug. Je n'avais pas forcément la réponse. Deuxième question, qui est peut-être plus inattendue quand on ne fait pas de l'infra, mais c'est quoi une production?

13:49 Parce que moi, j'ai des ingés qui sont venus me voir en me disant« Certes, j'ai une infra de production, c'est vrai, mais j'ai aussi tous des environnements de développeurs, j'ai plus de 150 développeurs qui travaillent du lundi au vendredi dessus. Est-ce qu'en fait, ça ne fait pas partie de ma production? » Je me dis« Ouais, c'est pas faux, effectivement. La définition d'un environnement de production n'est pas très claire. » Ensuite, il y a toujours la fameuse question de« ouais, mais c'est un bug en prod, mais ce n'est pas de ma faute, donc ça ne devrait pas être à moi de le regarder». En 2022, on a encore des« ce n'est pas moi, Ops, le problème, c'est le dev», et inversement, on y travaille beaucoup, mais ça arrive toujours, et puis ça peut arriver même entre différentes équipes de développement qui, pour le coup, se renvoient la balle. Donc là, je suis déjà... Un peu fatigué par ces questions, puis en fait moi j'en ajoute une autre à celle-ci qui est, regardez les bugs en production, c'est sympa, mais si vous avez déjà réussi à arriver à zéro bug en production pendant plus d'un an, allons prendre un café après, je vous l'offre, même s'il est déjà offert, parce que je me dis, ok, en fait on va faire l'équivalent de la JS fatigue, on va avoir la bug fatigue, on va en avoir marre de regarder nos bugs, on va se dire de toute façon on n'y arrivera jamais, et puis on va tous abandonner.

14:57 J'aurais pu remettre la photo de« Je me jette par la fenêtre», mais non. À ce moment-là, je n'ai pas envie de me jeter par la fenêtre. Et moi, je suis quelqu'un de très scolaire. Donc je me dis, OK, en fait, on va retourner à la théorie. C'est quoi une infrastructure de qualité? Donc là, je prends une feuille blanche ou en l'occurrence une page notion blanche. Et puis, je commence à écrire. Alors, j'aime bien avoir des anagrammes marrants. Donc, j'arrive à sortir le framework SSL au début. Je me dis, ouais, OK, c'est cool. Puis j'y terre. Puis je me dis, non, en fait, une infra de qualité, il faut qu'il y ait cinq piliers. Et puis, je décris ces piliers. J'écris, j'écris, j'écris. J'arrive à un framework qui s'appelle Marceau. Je trouve ça mignon. Et puis surtout, j'en discute beaucoup, beaucoup, beaucoup avec mon équipe de tech lead. Donc je pense que quand je me suis posée, je me suis dit, ok, je vais prendre trois jours à écrire et puis je vais sortir un truc et on va enchaîner. Non, en fait, ça m'a pris deux mois parce que quand on a une version, qu'on en discute, on se fait challenger, on dit, ah non, mais tu as oublié ça, puis je ne suis pas d'accord là-dessus, etc. Donc ça génère beaucoup, beaucoup de discussions. Je vais commencer à donner le mot qui sera assez clé sur ce talk, mais ça génère beaucoup d'engagement. Mais on est arrivé à un framework, alors qu'il y a toujours un nom sympa, parce que vous le savez, c'est important pour moi, un framework qui s'appelle Rose.

16:00 Donc on est arrivé à une théorie qui est qu'une infra de qualité, c'est une infra rose, c'est-à-dire qu'elle est résiliente, elle est opérable, elle est sécurisée. Et alors je suis désolée pour l'anglicisme, mais elle est empowering, ce qui veut dire qu'en fait elle est facile à utiliser pour les développeurs. Ensuite de cette théorie, qu'est-ce que j'en fais? Je la tourne en un jeu. Rappelez-vous la question de Thomas tout à l'heure. Je la tourne en un jeu, je me dis ok, sur ces quatre composantes, à chaque fois on peut avoir cinq critères. Par exemple, dans Home Powering, il y a le fait qu'une mise en prod doit être... faisable sans aucune action manuelle de la part d'un dev ou d'un ops. Puis je me dis, 5 critères, 4 catégories, ça fait 20 points. On peut gagner 1 point à chaque critère. Et puis l'objectif, c'est d'augmenter son score de semaine en semaine. Donc là, globalement, je me dis, on le teste sur un projet, c'est parti, on montre que ça marche, que c'est sympa, que c'est marrant, et ta dame, mais pas du tout. Ça, c'est le taux d'adoption de Rose dans les équipes PADOC sur 5 mois. Donc, comme vous le voyez, on peine à atteindre les 50%.

17:06 Et là, nouvelle péripétie, de nouveaux héros rentrent en jeu. Guillaume et Sacha. Guillaume et Sacha, c'est deux experts techniques chez Padok qui m'ont dit« Bon, c'est sympa ton truc, mais ça fait cinq mois que ça patine. Est-ce qu'on peut le reprendre? » Donc une fois que j'ai mis mon égo de côté, je leur ai dit« Ouais, ok, allez-y, je regarde faire. » Je leur ai donné le bébé et je fais une petite avance dans le temps, mais cinq mois après, ça donne ça. Donc cinq mois après, il y a quasiment 80% des équipes Padok qui l'utilisent. Il faut savoir qu'aujourd'hui, à date, on avoisine les 90-95% tous les mois. Du coup, comment ils ont fait? La première chose qu'ils ont fait, c'est qu'ils ont géré ça vraiment comme un projet. Ils se sont donné un objectif, ils se sont fait une roadmap, ils y ont mis de l'attention. Et ce n'était plus tellement un petit chantier comme ça à côté parce que c'est sympa, on a envie de parler de qualité. La deuxième chose, c'est qu'en fait, ils l'ont même géré comme un produit. Ils se sont dit... Le framework là, il est à destination des techs de Padok qui doivent l'utiliser. Donc en fait, on va aller faire des interviews utilisateurs. On va comprendre qu'est-ce qu'ils attendent de ce framework, qu'est-ce que ça leur apporte, qu'est-ce que ça ne leur apporte pas, pourquoi c'est compliqué de l'utiliser, etc.

18:16 Et puis, ils ont itéré là-dessus. Moi, je n'ai pas complètement rien fait pendant ces cinq mois. J'ai fait un truc, c'est que je me suis assurée que la qualité, ça devenait un sujet stratégique pour Padok. Ce que vous voyez là, c'est tous les KPI qu'on suit mensuellement avec notre COMEX. Et ils sont à la fin, certes, mais ils sont là. Il y a deux indicateurs qui sont liés à Rose. C'est le pourcentage d'équipes qui utilisent vraiment le framework. Et on n'oublie pas que l'idée d'avoir un framework, c'est surtout d'augmenter la qualité. Et donc, il y a aussi le pourcentage de projets qui arrivent toutes les semaines à améliorer leur fameux score Rose. Donc moi, je me suis assurée que justement, l'énergie qu'ils mettaient dans leurs projets, leurs produits, ils allaient pouvoir continuer à la mettre parce que le COMEX était sponsor de cette idée-là. Du coup, Rose V2 est née. Je passe les détails de Rose V2, mais si vous voulez en discuter, je pourrais même vous montrer Rose V3, enfin V2.1.0. Mais bref, on en discutera après. Donc vous avez l'idée, on a tous les deux des histoires assez différentes, mais en fait, il y a une recette commune, et je vais laisser Thomas vous la donner.

19:24 Donc on va voir si vous avez été très attentif. Donc c'est quoi les ingrédients un peu de cette recette? Alors le pâte. Premier, en fait, tous les deux avec Aurore, on a commencé par aller sur le terrain. La qualité, ça ne se comprend pas en regardant juste les KPI. Il faut aller concrètement voir comment ça se matérialise, soit en allant directement avec le développeur voir comment il développe, faire du pre-programming par exemple, ou alors faire un micro-trottoir. Donc ça, ça va générer la discussion qui va nous permettre de générer une théorie et commencer à créer quelque chose. Le deuxième, alors lui on l'aime bien parce que Elle est un peu controverse, mais il faut arrêter de regarder la production. Les bugs en production, c'est effectivement l'objectif, c'est grave, mais ça ne va pas vous aider à faire de la qualité. C'est dur à comprendre, c'est dur à analyser et c'est trop tard. Au lieu de ça, on regarde ce qui se passe en début de chaîne, soit on va comprendre comment on fait une bonne infra dès le début, on fait une bonne conception, soit on va comprendre comment on développe bien du premier coup.

20:26 Celui-là était assez facile, j'espère que vous l'avez eu. Effectivement, on a beaucoup gamifié nos frameworks, d'une part en créant un jeu de« write the first time» et en comptant et en créant de l'engagement autour de ça, où avec le score de Rose, on essaie d'avoir la meilleure note sur 20, et qui va permettre d'engager vos équipes. Et la dernière, c'est d'avoir aussi un expert ou des experts qui ont du temps et qui ont la compétence technique pour aller aider vos équipes à s'améliorer. Faire de la qualité, c'est dur, c'est très technique, il faut aller dans les détails. Et donc, il faut des gens qui ont cette expertise, que ce soit Guillaume ou Sacha, par exemple, chez Padok, ou Xavier qui, maintenant, m'aide à comprendre les défauts qu'on rencontre au quotidien. Résultat de cette recette, la première c'est l'engagement des équipes. En fait, faire de la qualité, c'est ce qui va permettre de créer la discussion avec vos équipes. Donc, il y a des choses qui en sortent. Ça permet d'avoir un sujet commun. Et puis, ça permet de générer de l'apprentissage qui fait qu'en tant que développeur, en tant que dev DevOps, on apprend des nouvelles choses et c'est hyper satisfaisant en fait.

21:36 Et bien entendu, le but final c'est de faire des produits de qualité qui généreront de la satisfaction pour vos clients, il n'y aura pas de bug, l'application sera performante, elle tournera bien, etc. Mais il y a quand même une grosse différence dans nos histoires. C'est que moi, quand j'entends Thomas qui me raconte un midi Rise the First Time, je me dis que c'est génial. Je me dis aussi que ça implique de vraiment changer sa manière de coder. Je pense que parmi nous, tout le monde a un jour essayé 20 fois, 20 trucs différents pour réussir à enlever cette erreur, savoir expliquer pourquoi c'était la dernière solution qui a fonctionné et pas forcément celle d'avant. Des fois, on ne s'y est pas tous intéressé. Donc je me dis, ok, c'est sympa, mais il faut mettre beaucoup d'efforts de pédagogie et de suivi pour réussir à changer finalement cette manière de coder et prendre un crayon avant son clavier. Et du coup, je suis un peu râleuse quand même comme personne. Et du coup, je me dis, facile quand tu es 15, mais quand tu es 50, moi, je n'ai pas le temps d'aller derrière chaque personne et rappeler qu'on essaye de changer et de faire énormément de pédagogie.

22:44 Donc la solution facile, ce serait de se dire, vous êtes moins de 10 dans l'équipe technique, tentez Write the First Time. Je pense que c'est très différenciant, je pense que ça aide vraiment à mieux coder et à mieux comprendre comment ça se passe sous le capot, dans les frameworks, etc. Et puis si vous êtes plus de 20, entre guillemets pas de chance, mais passez sur Rose, c'est sympa aussi, ça vous aidera à réduire votre nombre d'incidents ou de bugs en production, sachant que, disclaimer, mais si vous voulez un exemple de framework applicatif et pas infra, on en a un aussi, ça s'appelle 3S. Donc ça, ce serait la réponse facile. Mais en fait, le truc qu'on veut que vous reteniez notre talk, c'est qu'il n'y a rien à réutiliser à la maison. On ne vous conseille absolument pas de repartir avec Ride the First Time, on ne vous conseille pas de repartir avec Rose, on ne vous conseille pas de repartir avec le fameux 3S. Pourquoi? Parce qu'en fait, cette phrase, elle est... Extrêmement bateau, mais elle est extrêmement vraie, c'est que l'important c'est le chemin. On aurait pu rester sur le premier framework SSL ou passer sur Rose ou en avoir inventé un troisième, t'aurais pu t'intéresser aux défauts C, je pense, et pas A.

23:53 Qu'en fait, à mon avis, on aurait 1, toujours améliorer la qualité, parce que l'idée c'est qu'à un moment quand tu t'intéresses à quelque chose, tu t'apprends des choses, tu t'ères et du coup tu augmentes le niveau. Mais surtout en fait tout ça, ça nous a permis de créer de l'engouement, de créer de l'attention et de créer une identité. Je pense qu'aujourd'hui, les Oclaniens, le Rise the First Time, c'est un truc qui fait qu'ils sont fiers d'être chez Oclan, qu'ils ont envie de faire de la qualité et d'être toujours meilleurs. Rose, pareil, c'est vu comme un asset chez Padok et ça fait partie de l'identité de Padok. Donc, Oclan, I Rise the First Time. à Rose et nous on espérera que vous aurez autre chose. Et là normalement je passe à un slide, merci, est-ce que vous avez des questions, etc. Ce qu'il faut savoir c'est qu'on l'a oublié. Donc je vais rester sur ce slide là, mais merci à tous et si vous avez des questions, on est dispo. Je dis que ce n'est pas un talk technique, c'est plutôt un talk sur la théorie du changement.

24:54 On fait des blagues. C'est un peu systémique tout ça. Exactement. Bravo, j'ai reconnu beaucoup de trucs que je travaille tous les jours. Pareil, je ferai mon marché Aurore en police, comme prévu. On fait ça. J'ai vu qu'il y avait des mains qui se levaient. On va vous tendre un micro tout de suite pour que nos amis en remote... J'ai une question d'ailleurs de Tristan. Tristan est très assidu depuis hier. Il nous envoie plein de questions. Donc je pense qu'on peut lui faire aussi un grand coucou à Tristan qui est avec nous en remote. Ils sont 145 en remote, je tiens à vous le dire. Plus qu'ici. Ça fait beaucoup de monde. Pardon. Pascal Lécuio de Préligence. Merci beaucoup pour la présentation. En voyant les métriques roses, j'ai pensé tout de suite à Accelerate et aux 4 métriques clés. Et j'en profite pour faire la publicité. On l'a fait en book club avec la communauté. C'était super. Je trouvais ça génial. Ma question est assez ouverte. Dans quelle mesure ça vous a inspiré et dans quelle mesure vous avez vu des résultats par rapport à ces métriques? C'est une très bonne question, dans une très grosse mesure. Je pense que l'idée d'accélérer, c'est une très bonne théorie. Et par contre, si tu te rappelles ce qu'on disait, ne pas regarder la production, c'est quelque chose que j'ai essayé.

25:59 Mais effectivement, ça arrive tard. Il y a beaucoup d'équipes sur lesquelles jouer, il y a beaucoup de paramètres. Et donc l'idée, c'était de prendre Accelerate qui arrive entre guillemets en bout de chaîne et de se dire comment avec Accelerate, tu arrives à avoir de l'impact sur ces indicateurs-là, mais en regardant plus tôt. Donc ça m'a complètement inspiré pour répondre à ta question. Merci. Et j'en profite pour faire de la pub pour le Book Club. Je sais que ça a été largement dit hier, mais on peut continuer. Et ce matin encore. Et ce matin encore. Et encore merci à Marek. Oui, qu'on embrasse, qui sera bientôt là, je pense, cet après-midi. Petite question de Tristan avant. que quelqu'un d'autre se manifeste dans la salle. Christian nous dit, est-ce que l'approche« write the first time» ne serait-elle pas diamétralement opposée au traditionnel« fail fast, learn fast»? Tristan. Alors Tristan, très bonne question. Je pense que c'est exactement la même chose, c'est-à-dire que fail fast, on fail beaucoup plus vite que si on attend 4 mois d'avoir effectivement le fail en production. Là on fail au moment de coder, c'est« ah j'ai mal compris comment je centre un texte sur mon écran, j'ai fail tout de suite et j'apprends tout de suite».

27:00 Donc c'est l'inverse, c'est exactement ce même paradigme. J'espère que Tristan sera content de sa réponse, j'en doute pas, il nous le témoignera, parce qu'il est, comme je le disais, très assidu. Une autre question? Dans la salle sur cette formidable exposé de théorie du changement en interne et de susciter l'adhésion de l'ensemble du monde avec la gamification et surtout en allant chercher, en interrogeant les gens qui subissent le problème. L'encapacitation des personnes, c'est fondamental, on le sait bien, pour que tout le monde adopte les nouvelles pratiques. Ah, merci. On n'a jamais été aussi rapide sur le micro. C'est merveilleux. Bonjour, merci pour la présentation. Foued de chez Brigade. Comment, j'ai loupé le début du talk, donc peut-être que je pose une question à laquelle vous avez déjà répondu. Est-ce que l'équipe a... Senti ce besoin d'extra mile au niveau de la qualité? Ou est-ce que c'est... Et comment vous les avez accompagnés ?

28:02 Disons que la qualité était excellente au début, c'est un peu ce qui se passe chez Brigade. Et comment vous vous avez fait pour dire, OK, ce ressenti, c'est très bien, mais comment on va le matérialiser et le concrétiser dans votre démarche? Je vais commencer pour Padok. Je pense que moi, si je refais l'histoire, je m'y suis intéressée un peu tard à la qualité. Donc finalement, on était dans un moment où la qualité était moins excellente parce qu'on était plus gros. Donc en fait, il n'y avait pas forcément d'alignement. C'est un peu ce que je disais au début quand je posais la question, je ne sais pas si tu étais là à ce moment-là, de qu'est-ce que la qualité? J'avais plein de réponses différentes. Donc en fait, il n'y avait pas forcément d'alignement sur un sujet de la qualité. Donc il y avait des divergences d'opinion et du coup, un sentiment de ne pas faire de la qualité exactement partout. Donc justement pour revenir à ta question je pense qu'il y avait un besoin des équipes après ce qui est important c'est que je pense qu'on le vit tous, on a tous un besoin de qualité on a tous une pression du delivery et donc je pense que c'est au rôle du CTO, du manager de à un moment pouvoir remettre le focus et mettre un stop là-dessus je ne sais pas si ça répond à ta question

29:08 Et c'était sûrement différent pour Hokla. J'en profite pour signaler que Tommy nous a rejoints, vous pouvez le voir. Philosophie et développement, c'est toujours très, très lié, puisque vous avez, ah, on avait le dessin de Tommy, éventuellement, on peut le remettre sur le penseur d'Hokla. Elle est très bien, j'adore. Je pense que tout est dit. Réfléchir avant de coder, corrige tes défauts, réussir du premier coup, c'est mieux. L'important, Aurore, c'est le chemin. C'est exactement ça. La petite différence, En fait, moi, j'ai commencé ça très tôt parce que ça ne venait pas des équipes, ça venait vraiment de moi puisque j'adore ça. Je trouvais ça hyper intéressant de, intellectuellement, me poser des questions. Encore une fois, le penseur. Le penseur, très bien illustré. C'était une curiosité que j'avais, de comprendre tout. Mais attends, pourquoi ça ne marche pas? J'ai essayé de l'inculquer très rapidement aux équipes. Et après, la mayonnaise a pris. Mais je pense que la réponse d'Aurore, elle est très juste. Ça ne viendra quasiment jamais des équipes, ces sujets de qualité. C'est toujours, non mais là, j'ai corrigé, allez on passe à autre chose, regarde, il faut que je délivre, etc.

30:09 Donc il y a un rôle effectivement du manager et du CTO à finalement imposer ça ou à inculquer ça à vos équipes. Et en plus, c'est quelque chose qu'ils attendent. Pour moi, c'est quelque chose qu'ils n'arrivent pas à mettre en place parce qu'il y a toujours d'autres objectifs. Mais personnellement, je n'ai jamais vu un tech me dire non, mais je m'en fous de faire de la qualité là. Ou alors, c'est très, très circonstanciel à ce moment-là. C'est très bon aussi, pardon. On a un prochain dessin de Tommy Garif qui est très bon, c'est une petite dédicace pour Aurore, je pense. Une autre question, à monsieur, vous pouvez vous présenter? Bonjour, Nicolas de Tech.Rocks, merci pour le talk. Une question sur le côté, dans les conseils, ne pas regarder la prod et se concentrer sur la base. C'est toi qui disais que ça peut être un peu difficile. Du coup, c'est quoi ça peut être un peu difficile? Parce que c'est quand même vraiment à l'envers de beaucoup de choses quand tu vas voir tes équipes. Ou même voir un comex, un codire, leur expliquer« Ok, la prod, mais moi je vais plutôt m'attaquer à la base.

31:11 » T'avances comment là-dessus? Exactement, c'est ça qui est difficile. Votre comex, ceux qui ne sont pas techniques vous diront toujours« Mais ils sont là les problèmes, regarde, c'est qu'on a des bugs en production qu'on a des problèmes, donc il faut regarder ici. » Le souci, c'est que, comme j'ai expliqué, c'est pas en regardant les bugs en production. Quand je dis regarder, il faut quand même les mesurer, évidemment. Il faut s'y intéresser. Mais c'est beaucoup plus dur de s'améliorer en regardant les bugs en production. C'est beaucoup plus facile de s'améliorer en regardant le début de la chaîne, ce qui se passe vraiment à la racine. Donc, c'est en s'intéressant au début qu'on va réduire les bugs en production. Donc c'est ça qui est un petit peu dur aussi à expliquer. Je pense qu'il faut faire de la pédagogie avec l'équipe du comex, etc. Et ils l'entendront très bien parce qu'après, il faut suivre ça dans le temps. Et nous, on commence déjà à voir effectivement un décalage des défauts. On voit de plus en plus de défauts A, B et C et moins de D. Donc voilà, on a maintenant les preuves que ça fonctionne.

32:14 Pour compléter, nous par exemple dans les KPI, on suit aussi, on fait de l'infogérance, on suit le nombre d'incidents en production, qui notamment réveillent nos équipes 24-7. Donc l'idée c'est pas tant de ne pas les regarder, ça c'est quelque chose qu'on suit au niveau comex. Et en fait moi c'est mon rôle de me dire ok Rose ça aide vraiment à ça et on n'est pas juste en train de faire mumuse avec une théorie et se dire c'est trop bien on gagne des points toutes les semaines. Mais les équipes on les focus sur le début et c'est à nous en tant que CTO de garder l'attention sur la fin sans mettre toute l'énergie des équipes là-dessus. Une dernière question ? Madame, un micro arrive jusqu'à vous. Merci l'équipe Comet qui amène tous les micros à chaque fois. Nathalie Lamy, Netatmo. Merci, c'était très intéressant. Et moi, j'ai une question sur est-ce que vous mesurez le temps que vous consacrez à ces sujets de transformation par rapport au temps qu'on passe pour les produits? Alors ce serait faux que de répondre oui parfaitement.

33:17 Ce que je peux te répondre sur ce sujet-là, c'est que Guillaume et Sacha ont l'équivalent d'un mi-temps pour améliorer le framework, etc. Il y a tout un sujet, ils sont en train de créer une web app pour que ce soit plus interactif, parce que ça c'est je pense plus propre au service, mais un sujet de diffuser les nouvelles versions du framework quand on commence un projet. Donc c'est l'équivalent d'un mi-temps, ce qui est finalement assez peu sur une cinquantaine de techs. Moi je rajouterais juste que quand on aime, on ne compte pas. Surtout à 10 quoi en fait. Et d'autant plus, moi je n'ai pas la possibilité de mettre quelqu'un à temps plein là-dessus. Donc aujourd'hui c'est beaucoup moi qui le fais, mais encore une fois parce que j'aime bien ça. Et de plus en plus, les équipes, c'est le rôle du tech lead aujourd'hui de l'inculquer aux développeurs sur son équipe. Donc il faut s'assurer qu'il y ait une certaine diffusion de cette culture pour que ça marche. Cela dit, c'est un vrai sujet, ce que vous mentionnez, parce que ça doit faire peur. intégrante de certains postes en réalité parce que si on est dans un processus itératif en permanence pour faire pour améliorer les produits ça doit pas être un ice to have en réalité.

34:22 Exactement et ça prend du temps il faut le prendre en compte complètement. Et si je peux compléter là dessus c'est qu'il faut du temps pour créer ces outils là etc et surtout que ça fasse partie du process et par exemple rose c'est quelque chose que les équipes vont regarder toutes les semaines en fin de sprint au même titre qu'ils regardent la burn on chart ils regardent le score rose et donc en fait quand ça devient une habitude le fait de l'appliquer ne coûte pas de temps entre guillemets et par contre c'est l'entretien qui demande du temps. Et puis en plus, c'est un mot français, rose. Exactement. C'est chouette pour un framework. C'est féminin. Exactement. C'est une jolie couleur. Ce n'est pas le sujet. Merci beaucoup à tous les deux. Avec plaisir. Merci à vous.