La démarche qualité, une opportunité de croissance

0:14 Donc bonjour tout le monde, aujourd'hui du coup on va vous parler de la démarche qualité, une opportunité de croissance. On prendra vos questions tout à la fin du coup de ce talk, donc n'hésitez pas d'ailleurs si vous voulez monter sur scène, ce sera avec un grand plaisir de vous voir et d'échanger avec vous. Avec vous du coup moi c'est Farah Chabchoub, je suis Engineering Manager chez Ankorstore. Je m'occupe des équipes Productivity Engineering, Quality Tools et Quality Assistance, donc vous l'avez bien compris, je suis experte de la qualité et ce depuis plusieurs années et je suis surtout animée par le partage et c'est ce qui fait que je suis là aujourd'hui. Je laisse donc la parole à Florian et Thomas pour se présenter. Bonjour tout le monde, moi c'est Florian, je suis VP Engineering chez Shipup. Rapidement, on fait quoi? En gros, on propose aux e-commerçants, on a un produit qui suit, collecte, analyse les événements de livraison des commandes de leurs clients afin de leur donner la main sur cette partie post-achat, ce qui leur permet notamment d'être proactifs et de communiquer auprès de leurs clients via des notifications ou des pages de suivi de colis avec leur propre image de marque.

1:16 J'ai rejoint la société il y a un petit peu moins d'un an. Il y a un des sujets sur lesquels je me suis penché en arrivant. C'était justement la qualité, et non pas parce qu'elle n'était pas bien gérée, au contraire, mais plutôt pour mieux définir, expliciter. la stratégie qualité pour anticiper les prochains enjeux de croissance. Ça, on en reparlera tout à l'heure et je vais laisser la main à Thomas. Merci Farah, merci Florian et merci à Nouni de nous donner l'opportunité de parler de qualité aujourd'hui. Moi, je suis cofondateur et CTO de Hokla. On est l'antenne santé du groupe Théodo. On aide les acteurs de la santé à faire des produits en santé qui déchirent. Et bien évidemment, la qualité, c'est un enjeu majeur à la fois dans la santé et dans la tech, parce qu'on n'a pas envie de mettre en production des bugs dans des applications pour des patients. Et puis moi, c'est un sujet qui me passionne parce que je trouve qu'intellectuellement, la qualité et le software craftmanship, c'est ce qui me stimule pas mal. Donc, on voulait commencer par vous partager un petit peu nos expériences à chacun.

2:23 Et une méthode, tout d'abord, que je vais vous introduire, un peu innovante pour faire de la qualité en tant que développeur, que ce soit tout seul, freelance, dans une équipe ou dans une grande société. Et alors, j'ai cherché le moyen le plus farfelu de vous faire une introduction. Et j'ai trouvé, je me suis rappelé que lundi prochain, il y a Roland Garros qui commence. Donc, j'espère qu'il y a des amateurs de tennis parmi nous. Et je vais commencer par une petite devinette. Selon vous, quel est le point commun entre un développeur et un spectateur de Roland-Garros? Garros, un spectateur qui sera dans les gradins, pas forcément à la télé. Un petit indice, le dev et le spectateur, ils vont faire ça. Alors, s'il y a des développeurs parmi nous, j'espère qu'ils sont reconnus. En tout cas, je pense que si je vous rajoute ça, vous voyez un peu plus le lien que je fais. Si vous vous posez à côté d'un développeur, il va passer sa journée à passer de son I2, son éditeur de code, et de ce qu'il est en train de développer.

3:31 Une application mobile, une application web, un device, n'importe quoi. Et il va faire ce geste en permanence. Donc exactement comme quand vous regardez un match avec Raphaël Nadal. Vous allez regarder les échanges entre votre code et ce que vous développez. Et en fait, ce rapport, je l'ai fait quand j'ai développé une partie d'une feature sur une application mobile, un truc très très simple. On voulait centrer du texte sur notre application. Alors, s'il y a des... Effectivement, il y a aussi le geste du doigt qui peut marcher pour faire la table. Donc, si vous avez fait du CSS, vous savez à quel point c'est galère de centrer quelque chose sur un écran. Alors, quand moi, on m'avait demandé de faire ça, le premier fait que j'ai fait, j'ai regardé sur Stack Overflow, Natami, à tous, comment je fais pour centrer un élément. Et on m'a dit, c'est super simple, tu peux utiliser Flexbox. Ok, j'ai essayé Flexbox, j'ai regardé, à gauche, à droite, ça ne marche pas.

4:34 Bon, ok, qu'est-ce qu'il me dit d'autre? Ah non, tu peux utiliser TextAlign. Ok, gauche, droite, ça ne marche pas. Margin auto, machin et tout. Donc vous voyez ce geste qu'on fait tous en général quand on code. Et au final, je me suis arrêté, j'ai pris un papier et un stylo et j'ai commencé à dessiner. Qu'est-ce que je suis en train de faire? Comment ça fonctionne le système que je suis en train de modifier? Et c'était en faisant un schéma que j'ai codé un truc qui n'était pas finalement si facile que ça. Et en fait, ça marchait du premier coup. Et donc, ça m'a fait réfléchir vraiment sur cet enjeu de qualité. Quand on parle de qualité, j'ai l'impression qu'on parle souvent des bugs. Et c'est vrai. Je veux savoir si je suis un bon joueur de tennis. Si Raphaël Nadal est un bon joueur de tennis, moi, je peux regarder le nombre de balles qui finissent en dehors du terrain, en dehors du filet. Je vais regarder les fautes qu'il fait. Mais un autre moyen de voir si Rafael Nadal est un très bon joueur de tennis, ce n'est pas de regarder les balles qui finissent en filet, mais c'est de regarder les balles qui finissent dans le terrain.

5:41 Et plus particulièrement, c'est lesquelles les meilleures balles que fait Rafael Nadal. Moi, ce que j'adore regarder, ce qui m'impressionne tout le temps, quand j'étais gamin, je regardais toujours ça, c'est à quel point il peut faire des services rapides. Et quand il fait des aces, notamment, quand il fait un service et que la balle finit dans le terrain, il marque le point dès le premier coup. En fait, la qualité, c'est ça. Ça peut être aussi, non pas le nombre de balles qui finissent dans le filet, mais le nombre de meilleures balles qu'on arrive à faire, le nombre d'aides qu'on arrive à faire. Et si on applique ça, on monte du logiciel. On peut se poser la question, combien de fois j'arrive à faire right the first time, donc combien j'arrive à faire ma feature du premier coup, comme quand j'ai essayé de centrer... Mon texte sur mon application mobile. Du coup, ce que je vous propose de faire, c'est de jouer à ce jeu-là. C'est un jeu qui a des règles très simples, comme le tennis.

6:44 La première règle, c'est à chaque fois que je lance mon navigateur pour tester si la user story, la feature, le ticket Jira que je suis en train de faire est bien fait. J'ai passé ma journée à coder, je lance mon navigateur web, je regarde si ça marche. Si ça marche, c'est fini, je compte un essai, sinon je continue, et à chaque fois que je relance, je compte un nouvel essai. Si je fais un seul essai, j'ai fait« right the first time», j'ai fait un« ace», j'ai marqué un point, je suis super content. Et comme tout bon jeu a de nombreuses exceptions, j'ai rajouté une exception. c'est que je ne compte pas les tests unitaires. Donc si j'ai fait un test unitaire, il passe, il ne passe pas, ça ne compte pas comme un essai. Vous allez voir pourquoi c'est utile de faire cette exception. Nous, concrètement, chez O'Club, tout le monde joue à jeu là. Tous les développeurs chez O'Club jouent au jeu. Par exemple, si je prends Maxime qui a modifié le disclaimer sur une application mobile, a fait deux essais.

7:56 Il a lancé l'application mobile deux fois. Et donc il n'a pas fait un loi de first time. Pas de bol. Il y a eu deux échanges de balles. Maintenant, Ilam, elle a implémenté une autre feature. Elle l'a fait en un seul coup. C'est« write the first time». Vous avez compris l'idée. Alors, à quoi ça sert? On a essayé ça, c'était un peu pour... On voulait jouer à ce jeu-là, on trouvait ça marrant, et en fait, on s'est rendu compte de pas mal de choses. La première, c'est que ça donne envie de célébrer. J'ai fait un break the first time, je veux le partager, je suis content, je me lève dans l'open space, Je gueule un bon coup et puis les gens me félicitent. En vrai, en tant que développeur, je trouve quelque chose d'assez unique de pouvoir célébrer quelque chose assez régulièrement. Si je fais parallèle avec quelqu'un qui travaille dans le service commercial, à chaque fois qu'il fait une vente, il est content, il célèbre. Je sais que dans certaines boîtes, ils mettent un jingle, etc. En tant que développeur, nous, on n'a pas ce moment-là.

8:57 On l'a que très rarement, quand on va mettre en production, quand on a eu des tests utilisateurs qui sont retournés positifs. Et donc là, ça permet de créer un moment assez régulier. Tous les jours, on peut célébrer. J'ai fait un Red First Time, ça donne la patate. Il y a une satisfaction de réussir du premier coup. Nous, on est allé encore un peu plus loin puisqu'on a créé un petit chatbot qui va mettre un message sur le Slack avec tout le monde, qui va dire« Marie a fait un Red First Time». Et tout le monde la félicite, réagit, et ça crée une espèce d'émulsion. Le deuxième avantage, le deuxième intérêt de faire ça, c'est, si je reprends l'exemple du début, c'est de réfléchir avant de coder. Au lieu de faire du copier-coller, de tester des choses sans vraiment rien comprendre, là, on se force à réfléchir avant de coder. Comme on a un seul essai, on ne veut pas le gâcher, donc on va prendre plus de précautions. Est-ce que j'ai bien compris ce que je maîtrise? Comme ça, on va construire un schéma mental de« est-ce que mon système fonctionne comme je pense?

10:00 Il va fonctionner. Est-ce que le code que je suis en train d'écrire fait bien ce que je pense qu'il va faire? Et le dernier intérêt, c'est d'avoir une incentive à faire du TDD, donc à faire du Test Driven Development, à coder des tests en premier. Et donc ça, c'est grâce à la petite règle exceptionnelle que j'ai rajoutée. Quand on a le droit de faire des tests, je vais en faire plein pour m'assurer que je vais dérisquer au maximum mon ride de first time. Je vais assurer plutôt de le réussir. Si on n'y arrive pas, ça arrive, on ne fait pas tout le temps des aces quand on fait des services au tennis. Par contre, quand on a mis la balle dans le filet, on ne va pas tout de suite en relancer une. On ne se précipite pas, on va se poser la question, qu'est-ce que j'ai mal fait? On va peut-être repositionner nos épaules, remettre nos pieds alignés, prendre un peu le temps. Et nous, on va faire la même chose. On va regarder, OK, qu'est-ce qui ne marchait pas? On va regarder quel bout de code pensait être dysfonctionnel et pourquoi c'est le cas.

11:09 Et donc cet exercice va permettre de mettre à jour notre schéma mental de, en fait, quelle est ma compréhension du code et du système que je manipule. Donc en appliquant cette méthode en tant que développeur, tout seul, dans votre équipe, vous allez largement améliorer votre qualité tout en créant une... une émulsion, un partage collectif. Donc voilà, ça c'était la méthode des Bright of First Time. Je serais ravi de savoir si vous voulez l'appliquer et en discuter avec vous. Et j'invite... Du coup, Florian va venir sur la scène pour maintenant vous expliquer quel est l'impact de tout ça dans une société. Là, on parle d'une méthode que je peux appliquer moi en tant que développeur. Mais maintenant, qu'est-ce que je peux faire dans une boîte qui cherche à avoir de la croissance de l'appliquer? Excuse-moi, c'était Farah qui devait passer. Pas de souci. Merci beaucoup, Thomas. En tout cas, j'espère que vous avez tous compris la démarche.

12:12 En tout cas, l'idée maintenant, c'est de vous dire ce qu'en fait Thomas nous a dit aujourd'hui avec« Write the first time». C'est surtout une démarche. Où il a poussé les développeurs à se poser des questions tout en développement. Et cette démarche-là, en réalité, elle est encore plus loin, parce que si typiquement, ils ont raté des choses au moment des spécifications, ils vont avoir une manière d'itération pour leur permettre de faire, non seulement développer les bonnes choses, mais surtout des automatismes autour du test qui parallélisent le test et le développement, voire même qui anticipent les tests par rapport au développement. Et en fait, cette démarche-là, c'est ce qu'on appelle également le shift left. Donc le shift left. c'est de se dire on va faire la qualité le plus tôt possible dans le cycle de vie de notre développement pour pouvoir en fait dérisquer au maximum les mises en production. Et du coup, on va éviter d'avoir des problèmes une fois qu'on est en production.

13:16 Mais en fait, ce qu'on ne vous dit pas, et que vous savez sûrement, c'est que le bug zéro, c'est impossible. Ça n'existe pas. On a beau vouloir faire de l'automatisation, on a beau vouloir faire des tests, on va toujours avoir des bugs en production. Et en réalité, le pire scénario, c'est que quand on va mettre beaucoup d'efforts sur la partie test, et une fois on va mettre en production, on va être en attente, nos développeurs vont se dire, est-ce que j'ai quand même un bug? Est-ce que je vais avoir une avalanche de tickets support? Est-ce qu'en fait là, je vais avoir un incident majeur parce que j'ai cassé par exemple une intégration avec un service externe? Et c'est là où en fait l'angoisse commence. Et à ce moment-là, la question qui peut être posée, alors pourquoi on a mis la qualité? Alors à quoi ça a servi? Et en fait, moi j'ai vraiment envie de revenir sur l'essentiel, sur le pourquoi de cette démarche-là, dès le départ. Si on reprend un peu les choses, on pense à la vélocité opérationnelle.

14:16 Et là, je vous renvoie tous au backlog qu'on peut avoir dans nos équipes tech. En fait, notre backlog, il est divisé en différentes parties. La première, c'est la création de valeur business. C'est là où on va avoir peut-être des... pour créer de nouvelles features et faire évoluer des features également parce qu'on a de nouveaux besoins. Et donc, en réalité, innover, sortir des choses qui vont être ultra intéressantes d'un point de vue expérience utilisateur et qui vont nous permettre d'être pionniers peut-être sur le marché. La deuxième partie, sur la vélocité, c'est l'adaptation interne. On fait tous des choix dans le passé qui ont obligatoirement des répercussions sur le futur. Typiquement, on peut... peut avoir eu à créer de la dette technique, mais qu'à un moment donné, cette dette technique-là, il va falloir qu'on la gère parce qu'on a besoin de s'adapter, parce qu'on a besoin d'aller toucher à une partie spécifique de notre architecture. On a peut-être besoin de créer aussi de nouveaux microservices ou de faire évoluer nos process parce que les équipes ont énormément ce qu'elles ont.

15:20 Et en fait, ça, c'est nécessaire. Toute entreprise, elle a dans son backlog et dans sa vélocité opérationnelle l'adaptation interne. Et ça fait partie, on va dire, de l'histoire même de nos équipes. Et puis enfin, arrive la dernière partie. Et cette dernière partie, c'est la gestion de problèmes. C'est le temps que nos équipes mettent à gérer des incidents en production, à fixer des bugs, à prioriser des bugs dans nos backlogs et à les regarder. Et en fait, la question va se dire, où est-ce qu'on pourrait améliorer cette vélocité? Si je reprends cette question, Moi, je dirais, c'est là où on a de la valeur business. Et là où on a la valeur business, c'est la création du coût de valeur et l'adaptation. Parce que ces deux actions-là sont nécessaires et on ne peut pas s'en séparer. Et du coup, pour faire ça, un des moyens, c'est de réduire le risque sur la gestion de problèmes. C'est de rendre les incidents, les bugs, en fait, un non-événement dans nos sociétés et dans nos équipes.

16:24 C'est de faire en sorte que les équipes, quand on a un problème, on le maîtrise, on n'est plus… plus, on va dire, calme et concentré sur comment je vais faire et est-ce que je suis en capacité de le voir ou pas ou comment je le vois, plus que courir sur est-ce que j'ai bien détecté tous mes problèmes ou pas. Et une fois qu'on aura fait ça, en fait, on va améliorer la productivité sur l'adaptation interne et la création de valeur business. Et c'est là où, du coup, la partie qualité devient intéressante. Et donc, si je reprends un peu le schéma dont je vous ai montré au départ, et bien en fait, le spectateur de tennis, il est toujours là comme le développeur. Il va regarder à droite et à gauche, mais en fait, cette fois-ci, il va surtout regarder à droite pour, une fois qu'il a mis en production, il va observer les tendances et détecter s'il y a des problèmes, s'il y a des anomalies, et pouvoir du coup être dans une posture plutôt proactive que réactive.

17:26 Et qui ne va pas attendre que le service client l'appelle pour lui dire qu'il y a tant d'users qui n'arrivent plus à ce login. Donc cette démarche-là, c'est ce qu'on appelle le shift right. Et quand d'ailleurs je parle d'observer, ça ne va pas plutôt être sur des KPI du type est-ce que mon infrastructure répond ou pas, mais on va plutôt aller plus loin, regarder des indicateurs sur l'expérience utilisateur, comme par exemple si j'ai des moyens de paiement, est-ce que les paiements par exemple fonctionnent normalement et est-ce que mes clients arrivent à bien ajouter des articles dedans? leur panier, par exemple, pour une marketplace. Donc, ça va être ce genre d'approche. Et puis enfin, pour conclure, le shift right et le shift left, c'est une vision continue de la qualité. Certains projets, on n'a besoin que de faire du shift right, certains d'autres, on n'a besoin de faire que du shift left. Et à titre d'exemple, si par exemple, vous avez un site vitrine sur lequel vous avez juste des clients qui arrivent pour faire de l'onboarding, vous n'avez peut-être pas besoin de faire des tests unitaires et de faire une couverture incroyable partout parce que vous n'avez peut-être pas

18:31 énormément de besoins sur le sujet. Par contre, observez si vous avez des clients qui arrivent à se faire emborder normalement ou qui arrivent à se faire rediriger vers les bonnes pages normalement. C'est quand même intéressant à voir parce que c'est là où l'impact, il a vraiment un impact business. Donc voilà, c'était pour la partie du coup qualité continue tout au long du cycle de vie du produit. Donc, pour reprendre ce que disait Farah sur sa démarche de qualité continue, comment l'atteindre et surtout dans quel but ? Cette question d'impact, elle est essentielle notamment pour les leaders techniques, les leaders de la qualité, parce que finalement, c'est un peu notre rôle de s'assurer que l'investissement dans cette qualité a un impact sur le produit et sur le business. Finalement, être convaincu des bienfaits de la qualité ne suffit pas. Il faut s'assurer d'avoir une démarche qui est explicite et donc notamment de mettre en place ce qu'on peut appeler une stratégie qualité.

19:36 Si on ne le fait pas, finalement, les risques, c'est de mettre en place des pratiques notamment qui auront peu ou pas d'effet ou même de disperser les efforts. Donc cette stratégie qualité, comment elle se décline? C'est un petit peu l'objet de cette troisième partie de la présentation. Avant tout, on va chercher à comprendre... Comment la qualité va répondre aux enjeux business et notamment autour de deux aspects. Il y a celui dont parlait tout à l'heure Farah qui est comment réduire les risques, donc les risques d'indisponibilité du service, de fuite de données, de bugs dans les fonctionnalités majeures de l'application. Mais aussi comment finalement la qualité contribue à la croissance du business. Dans six mois, j'ai prévu d'avoir dix fois plus de clients, dix fois plus de volume d'activité. Comment ça se traduit dans le produit? Quels sont les attributs de la qualité sur lesquels je vais me concentrer, auxquels il faut faire attention et anticiper dès aujourd'hui? Deuxième et troisième point, se mettre d'accord sur ce que représente la qualité pour en déterminer les priorités.

20:46 La qualité étant une notion subjective, comment faire en sorte que l'organisation s'aligne par rapport à ces priorités-là? On va aussi chercher à un moment donné à savoir comment mesurer les résultats de cette stratégie qualité. Et enfin, mais peut-être pas le moins important, c'est comment cette stratégie se décline concrètement, d'un point de vue organisationnel, qui fait quoi, comment et quand, à quel moment. Alors si on commence par les enjeux business, ce qu'on observe et qu'a pu constater notamment Farah dans ses différentes expériences et je dirais qu'il résonne un peu avec les miennes, c'est que quels que soient les modèles de société, quel que soit leur environnement, on peut faire les mêmes observations. C'est-à-dire que généralement pour le sujet de la qualité, on va avoir toujours les mêmes impacts, des clients insatisfaits, mauvais time to market, des incidents à tout va.

21:47 Et les objectifs associés sont également les mêmes, pour gagner de la satisfaction client, livrer de la valeur plus vite et plus continue. Alors on n'est pas obligé de gagner tous les combats en même temps et la stratégie qualité nous permet notamment de se dire quels sont les plus importants, quels sont les plus urgents. Si on fait un petit peu le parallèle par rapport à la pratique Rise the First Time dont a parlé Thomas, ce qu'on va probablement chercher à atteindre c'est une réduction sur le time to market parce que justement je vais mettre moins de temps, je vais faire moins d'essais pour déployer mes fonctionnalités. Alors comment on fait pour s'aligner par rapport à ces objectifs business ? Déjà, je dirais que ça dépend d'où on part. Une situation qui n'est pas inhabituelle, c'est celle d'avoir touché le fond, finalement, avant de réagir. Et donc là, on va plutôt être dans un mode réactif. Si là, encore une fois, on fait le parallèle par rapport, on reprend l'analogie du tennis, quand un joueur est blessé, il va commencer par se soigner avant de s'entraîner à faire des aces.

22:54 Et puis il y a l'autre situation, celle dans laquelle j'opère actuellement, qui est une situation qui est maîtrisée. Là, en tant que tech leader, vous allez faire cet exercice qui consiste globalement à prendre le business plan et de se dire, ok, puisque dans X mois, mon volume d'utilisateurs, je ne sais pas quoi d'autre, mon nombre de documents à gérer va croître, quelles sont les initiatives que je vais devoir démarrer dès aujourd'hui qui vont avoir un impact sur cette croissance? Alors, une fois qu'on est aligné sur les objectifs, la question de la priorisation se pose, car évidemment, on ne dispose pas d'effectifs et de temps illimités. Donc, on va vouloir mettre de la qualité là où le ROI est le meilleur. Alors, comment on peut faire ça? Alors déjà, on peut faire un petit peu le tour des équipes et des clients. Et pour arriver à comprendre l'incidence de la qualité sur leur métier. On peut aller voir les sales par exemple et poser la question, tiens dis-moi, est-ce qu'on a eu des ventes qui ne se sont pas réalisées parce qu'on a eu des problèmes pendant les démos?

23:57 Est-ce qu'il y a des fonctionnalités avec lesquelles tu n'es pas à l'aise, que tu ne mets pas trop en avant parce que derrière tu sais qu'elle est bancale? On peut aller voir aussi les équipes de customer experience, de support. Est-ce qu'on a des clients qui ont churné récemment parce que l'application ne fonctionnait pas de manière régulière? Quelles sont les plaintes récurrentes qu'on a au support? Quelles sont les zones à risque? On peut aussi aller voir le marketing, finalement, comment la qualité peut contribuer à l'image de marque de la société. Une des promesses du produit Shipup, c'est de proposer une expérience post-achat rassurante. Quels sont les problèmes de qualité qui peuvent finalement remettre un petit peu cette image de la société auprès des clients? Puis on peut demander aussi, évidemment, à l'équipe produits et tech, et puis on l'a pu voir tout à l'heure avec Thomas, qui va avoir son propre opinion

25:00 son propre angle de vue de ce qu'est la qualité. Le deuxième point, c'est aussi de prendre en compte les spécificités de son domaine. Chez Shipup, par exemple, on est dans le secteur du e-commerce et donc on sait qu'on va avoir des pics d'activité pendant les périodes de fête de fin d'année et donc ça va tirer certaines priorisations. Alors, quelle approche? Et donc là, on attaque une partie qui n'est pas la plus simple à mettre en œuvre. Une fois les objectifs et les priorités définis, comment on va mettre tout ça en place et ne pas rester dans le monde théorique? Alors, premièrement, bien définir les responsabilités. Si on souhaite que la qualité soit une responsabilité partagée, alors il devient nécessaire d'expliquer comment chacun, à son échelle, par rapport à son métier, a un impact sur la qualité. Par exemple, un membre d'une équipe produit va contribuer de différentes façons. Il va par exemple vérifier que l'expérience utilisateur, l'utilisabilité, nouvelles fonctionnalités correspondent finalement à ce qui était sur le papier.

26:04 C'est lui ou elle qui va notamment pouvoir créer des jeux de tests et des scénarios proches des cas d'usage réel des clients parce qu'il a un accès plus facile auprès d'eux. Et pour un développeur, je pense que je n'ai pas forcément besoin de m'étendre, mais écrire des tests à différents niveaux, faire les code reviews, évaluer les risques de dénigrer les tiers, etc. C'est également explicité. Comment on fait de la qualité de manière continue ? Là, j'ai mis une capture d'écran finalement de ce qu'on peut faire dans ces différentes phases. On va décrire pour chaque étape du process de delivery quelles sont les activités concrètes qui vont avoir un impact sur la qualité. Je peux prendre un exemple ici qui est la revue des écrans, puisqu'on était sur la thématique des écrans. En début de cette présentation. Globalement, un développeur et un designer vont s'asseoir ensemble et se poser la question de, tiens, quels scénarios d'erreur peuvent arriver dans tel contexte?

27:11 J'utilise un composant de type liste. Qu'est-ce qui se passe quand la liste est volumineuse? Qu'est-ce qui se passe quand elle est vide? Comment on va pouvoir scaler? Et voilà, on va avoir tout un ensemble d'éléments à vérifier. Donc, on va faire cet exercice pour chaque étape du process pour vraiment donner, on va voir. Les aspects tactiques qui permettent de répondre aux objectifs initiaux. Et donc, ces objectifs initiaux, comment finalement peut-on jauger du niveau de la qualité? On peut déjà se baser sur ce qu'on peut appeler les indicateurs externes, comment la qualité est perçue d'un point de vue utilisateur. Et donc, si votre situation initiale était un mécontentement client lié à... à un trop fort nombre de bugs fonctionnels. Vous allez peut-être juger inutile de suivre la fréquence des bugs trouvés en production, ainsi que la satisfaction client après X mois pour être sûr d'avoir corrigé le tir.

28:15 Par exemple, encore chez Shipup, un des indicateurs qu'on va suivre, c'est la proximité dans le temps entre l'état actuel de la livraison d'un colis et l'envoi de la notification au client qui l'avertit sur l'état de ce colis. En gros, si on envoie une notification de colis arrivé en point relais deux jours après que celui-ci soit réellement arrivé, on va avoir des problèmes. Et puis il y a les indicateurs internes. Comptez le nombre de rides the first time, c'est finalement un indicateur du temps passé à refaire des choses, qui va lui-même influencer sur le time to release. Et donc je vais laisser la main à Farah qui voulait notamment un petit peu revenir sur la partie indicateur qui est liée à la vélocité opérationnelle. Merci beaucoup Florian. Donc du coup, si on reprend, parce que là on parle de métriques, et vous pouvez vous poser la question, alors Vara, ce qu'on a vu tout à l'heure avec le shift left et shift right, c'est quoi comme métriques? En fait, c'est des métriques qui sont énormément inspirées du framework space.

29:19 Je ne sais pas si vous connaissez, c'est la même personne qui a écrit le livre Accelerate, qui a sorti ce framework-là l'année dernière, et qui parle en fait de métriques qui sont les deux rares métriques. C'est les métriques pour s'assurer que l'équipe est assez productive et qu'on est plutôt bon d'un point de vue productivité, mais également sur la qualité de ce qu'on produit. Si on reprend notre schéma, vous pouvez voir que le temps entre la spécification et la livraison, c'est le lead time. Le temps entre le développement et la livraison, c'est le cycle time. Et en fait, en réalité, ce qu'on va essayer à chaque fois de mettre en place en termes de pratique, on va vouloir pousser à améliorer. des métriques bien spécifiques. Et donc, ici, vous pouvez voir les différentes métriques qu'on peut pousser. Et généralement, les métriques vont ensemble. Donc, par exemple, on va plutôt chercher un cycle time qui est réduit et un time to detect, par exemple, qui est également réduit. Ou un lead time. Qui va très bien avec un recovery time, parce que du coup, plus on va augmenter la productivité sur la partie de spécification à livraison, plus on va avoir plus de proactivité à gérer les incidents et à les fixer.

30:34 Ces métriques-là, c'est des métriques plutôt pour les équipes tech. Mais vous pouvez me poser la question, mais Farah, si demain, moi, j'ai mon CEO et qu'il me demande pourquoi j'ai besoin de recruter une équipe qualité, des experts qualité, ou pourquoi je dois augmenter le temps sur ces projets-là, quels sont les KPI que je peux également pousser? Et là, la discussion commence à être encore plus intéressante. Et avec un lien direct avec ce que Florian nous a dit, c'est qu'on peut également aller regarder des indicateurs comme combien on a eu de 15 000 MRR, combien on a eu de churn dû au manque de la qualité. Et en fait, avec ces KPIs-là, on a en réalité un impact direct sur le business, qu'on peut démontrer et en parler avec son CEO sans avoir aucune difficulté de compréhension de quoi on parle. Parce que si on commence à parler de doramétrique, on va peut-être avoir plus de mal à faire passer le message. Donc voilà. pour les métriques que nous avons. J'en repasse donc la main à Florian.

31:36 Finalement, non, je pense, je m'excuse. C'est les aléas du direct. Donc, ainsi, nous avons achevé du coup notre talk. N'hésitez pas si vous avez des questions. Je vois qu'on a une question actuellement dans le Q&A. Nous avons également écrit ici nos inspirations. On s'est beaucoup inspiré ici de Accelerate, de Agile Testing, donc des deux ramétriques dont je vous ai parlé. Et du coup, on va prendre la première question. Et n'hésitez pas, d'ailleurs, si vous voulez monter sur scène, ce sera avec un grand plaisir de vous voir en vrai et du coup d'échanger autour des questions que vous avez. Donc, la première question que nous avons, c'est comment faire passer une équipe et une code base avec très peu de tests à une démarche presque TDD? Quel prio? Comment faire adopter la philosophie test à l'équipe? Je laisse Thomas répondre à cette question. Alors, je pense que c'est une très bonne question et il y a deux approches différentes. La première, c'est de dire, bon, faire des tests, c'est important.

32:39 Regardez, ça permet de réduire les bugs, c'est les bonnes pratiques. Si, si, faites-le, vous allez voir, c'est cool. Et ça peut marcher, c'est-à-dire qu'il y a des gens qui sont très sensibles à ça et ils vont l'adopter. Maintenant, il y a une autre approche qui est plutôt de... positiver le truc et de dire, essayez la méthode des« write the first time». En fait, vous allez voir que c'est très dur d'en faire un, de« write the first time». On a toujours un petit truc auquel on n'avait pas pensé, un« h-case», on pensait que ça marchait comme ça, ça ne marchait pas comme ça. Et en fait, spontanément, on va comprendre l'intérêt de faire un TDD. Faire du TDD, faire des tests, ça permet de dérisquer le loi de first time. Et c'est hyper satisfaisant. Donc en fait, on ne touche pas même au canal émotionnel, il y en a un où on touche un petit peu au cerveau rationnel. Je suis en train de te dire que c'est une bonne chose, est-ce que tu l'entends?

33:41 L'autre, c'est plus émotionnel. Si tu veux réussir, si tu veux avoir la satisfaction de faire un loi de first time, tu vas voir que tu vas avoir besoin de faire du TDD. Donc c'est un des mots de réponse que je vous invite à essayer. Merci beaucoup Thomas. Et si je peux compléter, je pense qu'également, ça dépend en fait dans quelle temporalité vous voulez faire le changement. Si vous voulez faire le changement d'une manière rapide, on va dire, et vous avez besoin absolument d'avoir des tests et d'instaurer, on va dire, cette culture, il va falloir faire un choix qui va être plutôt radical. Et par exemple, moi, dans mon entreprise actuelle, Ankorstore, on a beaucoup, beaucoup scalé. On est passé de 20 personnes côté tech à 180 personnes. Et donc, du coup, on avait énormément peur, en fait, qu'avec cette scalabilité, on perdait la culture. qualité. Et donc, qu'est-ce qu'on a fait? On a fait un choix assez radical, mais simple. C'est qu'on s'était dit, maintenant, plus aucune PR peut passer s'il y a en dessous de tel niveau de code coverage.

34:43 Et donc, c'était une manière assez radicale. Et en fait, tous les développeurs se sont retrouvés à rajouter des tests unitaires, des tests de features et d'intégration. automatiquement, et on a fait ça assez rapidement. Si on voulait le faire d'une autre manière, parce qu'on aurait eu plus de temps, là, peut-être qu'on aurait fait une démarche où on aurait fait des guidelines, accompagné les équipes petit à petit, et faire instaurer le changement, on va dire, d'une manière graduelle dans le temps. Donc, on a une seconde question de Pierre que je vois. Donc, l'évolution dans le temps des métriques de RAS sont symptomatiques de la qualité d'une stack. Suivez-vous d'autres métriques plus représentatives de la qualité, comme le ratio code de test, code prod. Alors, c'est une très, très bonne question. Pour être honnête, il y a beaucoup, beaucoup de métriques sur la qualité. Moi, par exemple, avec mes équipes, ce qu'on suit également, c'est le nombre de tickets support, parce que c'est quand même assez révélateur de ce qui se passe, en fait, sur la production.

35:49 Parce qu'en réalité, on peut regarder la couverture, on peut regarder combien on teste, etc. C'est très difficile de savoir si on teste bien les bonnes choses, si on a bien remonté les bonnes choses. Et en fait, pour être aussi franche avec vous, moi, par exemple, la partie code coverage, je trouve ça difficile à réaliser à combien ça a d'impact sur le temps. Et donc, on va plutôt regarder avec mes équipes vraiment des KPI où on peut voir l'impact direct sur les utilisateurs que je trouve vraiment énormément powerful. Donc, j'espère que j'ai répondu à ta question, Pierre. On a une autre question. de page Anaïs, si je ne dis pas de bêtises. Donc, quelles astuces auriez-vous pour faire adhérer globalement les personnes à une culture qualité? Je ne sais pas si Florian ou Thomas, vous voulez prendre la question. Oui, juste, il y a quelqu'un qui veut monter sur scène. Ah! Je vais l'inviter à monter sur scène pour poser sa question.

36:55 Merci à tous. Je fais une entrée un petit peu où je me jette sur scène. Merci déjà pour le talk et pour tous ces retours d'expérience. De mon côté, je suis Arthur Mann, CTO et cofondateur de Promise. On est spécialisé dans la qualité logicielle et dans tout ce qui va être à compter. A diffusé un petit peu des cultures de qualité. Donc l'idée juste c'était que je partage très rapidement le retour qu'on avait avec soit des scale-up, soit des ESN, soit des grands comptes, soit des startups, soit des PME. En fait c'est vrai que la plupart des questions qui sont posées sont super intéressantes ici parce que la problématique qu'on a vu aujourd'hui dans les équipes, ce n'est pas forcément le fait que certaines personnes puissent bien comprendre le TDD ou les démarches de qualité, mais c'est comment est-ce qu'on fait. Adhérer tout le monde, surtout lorsqu'il y a du turnover ou quand il y a pas mal d'onboarding à avoir dans les équipes, pour faire adhérer vraiment tout le monde dans la durée à ces éléments-là. La partie métrique, on avait beaucoup travaillé dessus aussi en recherche, sur tout ce qui était indicateur de couverture de test, couverture de test,

38:00 test par mutation, indicateur sonar aussi pour tout ce qui était technique. C'est quelque chose qui, au fur et à mesure des années, j'ai l'impression, depuis 5-6 ans, a été un petit peu mis de côté par des équipes. Il y a eu, il y a quelques années, vraiment un engouement autour de ça. Et aujourd'hui, les équipes de développement, surtout avec les mouvements craft, donc software craftsmanship, etc., ont tendance à un petit peu faire attention à ces indicateurs qui malheureusement des fois peuvent être utilisés plutôt par des managers pour voir si on a une mauvaise note sur la qualité de notre projet. Ça doit être à cause de ça qu'on a des problèmes en production et à cause de ça que les clients boudent un petit peu notre produit. Et souvent, on a des effets qui sont un petit peu liés à la loi de Goodhart qui dit que lorsqu'un indicateur devient un objectif pour l'équipe, comme la couverture de test, ça peut avoir tendance justement à dire que ce n'est plus un bon indicateur parce que tous les efforts de l'équipe peuvent aller dans l'atteinte de cet indicateur. Et on s'est retrouvé aujourd'hui avec pas mal d'entreprises où on avait des tests rajoutés qui en fait n'avaient aucune assertion ou alors des méthodes qui étaient trop grandes découpées avec méthode underscore partie A et underscore partie B.

39:04 Des choses de ce type-là. Et c'est vrai que du coup, c'était assez problématique pour les équipes. Et donc, de plus en plus maintenant, ce qui est mis en place, d'après ce qu'on a vu, une communauté de pratiques ou juste des... Dans les équipes et c'est ça qui permet d'intégrer vraiment ces démarches. Et c'est vrai que souvent, ce qui se passe bien, c'est quand des gens qui sont coachs, on va dire, sur la partie test ou sur la partie qualité de développement, peuvent être intégrés directement. dans les équipes, pour accompagner aussi des personnes à mettre en place du TDD, par exemple, On a vu pas mal de contextes des banques, des assurances, où ils ont fait des grosses formations TDD à des centaines ou des milliers de développeurs. Qui a été un échec assez phénoménal, où en fait, après deux, trois jours de formation, des gens en revenant sur leur code d'égacie, se sont rendus compte qu'en fait, tout ce qu'ils avaient vu sur des exemples théoriques très simples, ils ne pouvaient pas l'appliquer sur leur base de code comme ça, c'était beaucoup plus compliqué que ça. Et du coup, ils ont changé un petit peu leur manière de faire. Ils se sont dit, on va plutôt prendre des coachs, des gens qui sont des gens qui sont des coachs, qui vont nous accompagner, ou alors des techniques en interne qui vont s'occuper de ça. Et qui derrière ont permis d'accompagner les équipes en faisant des ateliers toutes les semaines, des coding dojo, des katas, des choses comme ça.

40:11 Mais c'est vraiment beaucoup plus compliqué effectivement que ce que des gens peuvent penser des fois lorsqu'ils se disent on va juste mettre en place par exemple une culture un petit peu qualité. En fait, il y a une animation aussi à voir autour de ça. Et donc, il y a plein de rôles qui émergent aussi d'Evrel ou d'animateurs de communautés de pratique ou de coachcraft dans les équipes qui permettent justement d'initier un petit peu ça. Mais c'est assez récent, on va dire que ça a peut-être un ou deux ans où vraiment là, on a une explosion du nombre de coachcraft un petit peu partout en France et des entreprises comme Marola, Octo ou Publicis qui se positionnent vraiment sur ces sujets-là. Mais voilà, pour mon retour en tout cas sur tout ce qu'on a pu voir aujourd'hui dans les différentes équipes. Merci beaucoup, Arthur, pour le partage. C'est très vrai. Et je pense que ça vient également beaucoup avec la culture de nos tests qui vient de beaucoup d'entreprises, typiquement, par exemple, Shopify, qui ont zéro QA. Moi, par exemple, pour la petite anecdote, chez Ankorstore, mes équipes font zéro automatisation. On est plutôt là, comme je le disais au départ, on est plutôt là pour mettre les guidelines, les tools, pour vraiment animer ces community practices.

41:17 C'est exactement ce qu'on fait aujourd'hui chez Ankorstore. Et oui clairement c'est un mouvement et on va voir comment va évoluer le secteur de la qualité dans le futur mais en tout cas très très intéressant ton retour Arthur merci d'avoir monté sur scène et d'avoir partagé ça avec nous je vois qu'il nous reste deux questions Donc, on va te descendre, Arthur, si tu veux bien, du stage. Merci. Et on va prendre le reste des questions qui nous restent. Donc, du coup, on a la question d'Analyse. Donc, quelles astuces auriez-vous pour faire adhérer globalement les personnes à une culture qualisée? Thomas, Florian. Je pense que j'ai un élément de réponse, après je te laisse avec Florian compléter. Selon moi, il y a une proposition de valeur assez importante en tant que développeur. On cherche toujours à progresser et à apprendre individuellement.

42:20 C'est quelque chose qui est en chacun de nous. Et le message de dire que la qualité, en fait, c'est un moyen d'apprendre et de devenir le meilleur développeur, en tout cas, chez nous, c'est quelque chose qui marche bien et qui fait adhérer cette culture qualité aux équipes. Je pense que c'est une approche possible de dire, toi individuellement, si tu veux pour essayer, en fait, on a un moyen pour le faire et c'est de faire de la qualité. Ça passe par faire l'analyse des bugs, comprendre pourquoi on a eu tel ou tel bug. Ah ben en fait, si je retrace à... Sur cette ligne de code là, on l'avait écrit comme ça parce qu'on pensait que cette fonction faisait autre chose, parce qu'elle a été mal nommée. Ah en fait, je me rends compte que je ne sais pas très bien nommer mes variables. Et du coup, je vais creuser le point et en fait je vais devenir meilleur. Donc en passant par l'apprentissage, je pense qu'on peut faire adhérer à une culture qualité.

43:21 Je ne sais pas si tu as quelque chose à ajouter. Je ne sais pas s'il y a vraiment des astuces, tellement ça peut être un combat qui dure dans le temps. Mais peut-être que faire ressortir ou mettre l'accent sur des résultats particuliers liés autour de la qualité peut aider. Typiquement, quand on fait du code review et de voir qu'il y a une attention particulière sur notamment la partie test, la qualité de code, etc., d'en faire un commentaire et peut-être même de le mettre dans votre channel Slack pour indiquer que c'est ce type de code qu'on cherche demain. Et avec probablement la légitimité technique que vous pouvez avoir ou qu'ont certaines personnes dans les équipes, je pense que ce sont les mieux positionnés justement pour transmettre cette culture-là. Très, très vrai. Et clairement, sur ce sujet-là, moi, je pense qu'il faut toujours avoir en tête que ce soit la qualité ou n'importe quelle démarche.

44:24 En fait, c'est comme ce qu'on disait sur le tennis. On ne peut pas obtenir des sportifs de haut niveau du day one. Il faut aussi être assez réaliste sur les objectifs qu'on veut se donner pour ne pas aussi être déçu et décevoir les équipes parce qu'on se donne comme objectif. Donc, il faut en fait trouver plutôt les petites étapes qui font à la fin qu'on arrive à être un énorme champion et ne pas essayer d'être champion du premier jour parce que généralement, ça ne marche pas trop. Il faut avoir le mindset du champion. Mais il faut surtout avoir les étapes pour y arriver. Et ça me fait une belle transition, du coup, pour... La dernière question que nous avons, n'hésitez pas à continuer à poser vos questions, on est là pour les prendre jusqu'à 13h. Donc du coup, Guilhem qui nous dit en mode remote, dans une équipe convaincue par les tests, mais qui n'a pas le réflexe d'en écrire, comment bien communiquer sur la mise en place des outils et d'écriture de nouveaux tests? Thomas, Florian, est-ce que vous avez une réponse pour Guilhem? Je voulais juste rajouter pour la question juste avant sur la culture qualité, comment la mettre en place.

45:29 Un élément essentiel, c'est vraiment le partage. Pour créer la culture, il faut que les gens montrent ce qu'ils font, ce qu'ils ont appris, ce qu'ils ont réussi à faire, les succès qu'ils ont eus, les échecs aussi. Donc, créer cette culture du partage, ça passe par des petits tips comme faites un channel Slack, vous en parlez régulièrement, faites des moments dédiés à ça. Nous, on fait ce qu'on appelle un dojo qualité. On va à quelqu'un qui va présenter quelque chose qu'il a appris et on en discute. Donc, pour créer cette culture, il faut créer ces moments et partager les essentiels. Ce que j'allais dire, c'est que cette question me fait penser à une autre question. Et quand je lis que quelqu'un est convaincu par les tests, mais n'a pas le réflexe d'en écrire, je me dis qu'il y a quelque chose qui est une forme de... C'est logique. S'il n'a pas le réflexe, comment qu'il est? Est-ce que c'est de la formation? Ou est-ce qu'il pense ne pas avoir le temps?

46:30 Donc là, ça peut aussi signifier qu'il y a une pression trop forte autour du delivery. Donc, il faut souvent, les personnes notamment qui vont un petit peu à reculons sur la qualité, il faut souvent essayer de chercher quelles sont un peu les raisons derrière et vraiment aller au fond du sujet pour arriver à trouver la bonne clé qui permet de... De débloquer ça. Je compléterais, sûrement si cette personne a compris mais ne le fait pas, ça veut dire qu'elle ne sait pas qu'elle ne sait pas. Et pour faire passer de quelqu'un de je ne sais pas que je ne sais pas, je sais que je ne sais pas, en fait il faut faire face au problème que ça engendre. Donc ça passe par exemple par l'analyse de bug. En fait, j'ai fait ce bug parce que je n'avais pas fait de test. En fait, je comprends que c'est vraiment important. Et en faisant ça répétitivement, parce que c'est un geste qu'il faut pratiquer, je pense que c'est quelque chose qui devient un réflexe. Je ne pourrais pas ne pas être aussi d'accord avec ce que vous venez de dire, Thomas et Florian.

47:35 Clairement, il y a parfois ce déni et le déni, il faut en faire prendre conscience. On enchaîne avec la question de Cédric qui nous dit, par curiosité, est-ce que lors des entretiens de recrutement sur ce sujet est abordé par les candidats pour en savoir plus sur votre culture qualité? Moi, je dis, là-dessus, j'aimerais bien répondre à cette question. Par exemple, chez Ankorstore, on fait vraiment, vraiment ultra attention à ça quand on prend de nouveaux développeurs avec nous sur à quel point ils sont sensibles à ce point-là. Donc, on pose des questions pendant les entretiens. En plus de ça, dans les premiers jours d'onboarding, on les fait prendre les tickets support pour qu'ils voient les bugs que les clients remontent et comment les régler. Et donc, du coup, dès les premiers jours, ils vont régler les bugs et donc mettre les tests qu'ils vont avec. Et en plus de ça, en fait, ce qu'on fait, c'est que... Sur le growth framework, donc sur leur évolution de carrière, on a des notations en fait sur les différentes sensibilités, également qualité, craft.

48:43 Et en fait, là-dessus, du coup, s'il n'y a pas un certain niveau en termes d'implication, d'écriture de test, de culture sur la qualité, les personnes peuvent se retrouver à ne pas pouvoir évoluer dans le temps. Et donc, du coup, c'est un peu comme ça. est généralement un très bon moteur de pouvoir créer en réalité de l'adhérence à ce sujet-là, parce qu'on sait très bien qu'il y a un impact sur leur carrière directe et donc sur leur salaire. Et donc, on a vraiment fait une démarche assez jusqu'au boutiste, je dirais. Et aujourd'hui, ça fonctionne plutôt bien. Les personnes qui en prennent, ils sont plutôt assez convaincus et ils ont notre mindset et ils contribuent dans ce sens. Je ne sais pas si Florian ou Thomas, vous voulez continuer sur ce sujet? Peut-être ce que j'ajouterais, c'est que pendant les entretiens, je pense qu'il faut quand même jauger aussi le niveau de séniorité, parce qu'on va s'attendre à peut-être une réponse différente en fonction de l'expérience du développeur.

49:45 Et qu'un développeur junior soit moins attentif ou ait moins de connaissances par rapport notamment aux notions de test, c'est moins grave, parce que notamment dans les parcours scolaires, ce ne sont pas forcément des sujets qui sont beaucoup abordés. Donc, on ne peut pas s'attendre à ce qu'il ait découvert, il l'ait appris par lui-même. Ça, c'est moins gênant pour un développeur plus senior. Effectivement, c'est quelque chose qu'on peut regarder. Quelque part, la question demandait aussi, est-ce que les candidats posent des questions autour de ces sujets, sur la culture qualité de l'entreprise? Je dirais que c'est variable. Ce que j'ai pu remarquer, c'est que les développeurs juniors sont très attentifs à la façon dont ils vont pouvoir progresser dans l'entreprise et de savoir à quel point la vigilance, quelle vigilance peut apporter sur le code, sur la code base. Donc, je retrouve plus dans ces questions-là chez les développeurs juniors. Ce que je peux compléter sur cette question, nous on met effectivement cette culture dès l'entretien, parce que notre premier entretien c'est un test de refactoring.

50:58 On donne au candidat un code qui est très spaghetti, vraiment très... C'est le jeu de termes très dégueu. Et on lui dit, il faut que tu rajoutes une feature. Et on voit tout de suite, d'une part, c'est de la sélection, parce que ça permet de voir le candidat qui va penser à faire des tests, à essayer d'être pragmatique, comment tu te débrouilles avec une code base qui est existante. Et en vérité, quand on intervient sur les projets, c'est régulièrement comme ça. Et en plus, ça permet de... au moment du débrief, d'avoir une discussion sur la qualité. Et donc, si c'est un sujet qui vous intéresse, moi, je peux vous montrer un petit peu comment on fait cet entretien, qu'on a déjà pas mal peaufiné et qui, effectivement, marche pas mal pour introduire la qualité. Merci beaucoup Thomas et Florian. Je ne sais pas si nous avons une dernière question. Il est 55, je ne vois pas d'autres questions. Je ne sais pas si également il y a des gens qui veulent monter en stage.

52:01 Comment se former à cette méthode? Donc, j'imagine... J'imagine du coup la méthode pour les entretiens. Je n'ai pas trop le contexte, malheureusement. Je cherche si c'est... Bonjour, merci pour le meet-up. Je me permets d'intervenir parce que je suis en train de... Moi, je travaille sur un produit en ce moment, sur justement montrer plus d'indicateurs sur la qualité de stack, sur des techniques, etc., sur ces problématiques-là. On est en pleine phase de discovery, on a fait plus d'une soixantaine d'interviews avec des CTO et des tech leads. Et clairement, le besoin de pouvoir fédérer ces équipes, ces équipes de dev, aux bonnes pratiques de dev, à la qualité, etc. C'est un des plus gros pains qui remontent dans les interviews. Et nous, on a commencé à développer un produit pour aider les tech leaders à remonter plus de métriques pour embarquer le type de dev.

53:06 Et en fait, on se rend compte qu'en remontant des métriques type la modularité, dans tout ce qui est clean archi, etc., les pratiques de craftsmanship, En fait, il y a beaucoup de juniors qui ne savent même pas ce que c'est. Et rien qu'en parlant de la métrique, en montrant la métrique, ils se disent« Ah, c'est intéressant, je vais aller voir ce que c'est. » Ils reviennent, ils sont formés et ensuite, ils travaillent dessus. Et donc, en fait, il y a vraiment un travail de… Aujourd'hui, dans les formations de dev, dans l'école, etc., toutes ces pratiques-là, on ne les apprend pas. Et avoir un outil, quel que soit le type d'outil, quel que soit le format que ça prenne, mais avoir quelque part un truc qui dit, la clean archi c'est tel principe, le T. DD, c'est ça, etc. Ça éveille la curiosité et ça permet de facilement transmettre la connaissance. C'est ce que j'avais à dire. Totalement, Pierre. Assez d'accord avec toi. Moi, je sais, par exemple, de mon expérience, actuellement, chez Ankorstore, on a fait une newsletter interne dans les équipes qualité où on donne des informations sur qu'est-ce qu'on a mis comme nouveaux outils, comme nouvelles pratiques, etc.

54:14 Toutes les deux semaines, on cherche ça avec les équipes. Et parfois aussi, on fait des sessions support sur comment écrire de bons tests. Et en fait, on a plein, plein, plein de développeurs qui viennent et qui sont juste curieux. Au départ, ils viennent sans même avoir testé une seule fois comment mettre un test end-to-end, par exemple, et ils viennent avec la curiosité. Et en fait, ils sortent. On en a un développeur, par exemple, il est venu une fois et après, il est sorti. Et tous les jours, il mettait de nouveaux tests. Et tous les jours, limite, il a changé le framework lui-même et tout. Et donc, on voit qu'en fait, ça fait vraiment des déclencheurs. On a des déclencheurs comme ça. Et ça vient avec beaucoup de communication et de la création, en fait, d'intérêt autour du sujet en réalité. Tu peux me permettre? Juste de rajouter un point, c'est que nous, ce qu'on constate aussi, là, parce qu'on est en train de déployer notre produit chez les clients, c'est qu'en fait, avoir des indicateurs qui évoluent dans le temps, ça permet de motiver les devs à regarder cet indicateur. Et bien sûr, il y a l'effet, j'ai envie de le faire monter, je fais n'importe quoi.

55:17 Ça, c'est des choses qui arrivent. Mais en tout cas, on remarque qu'il y a une motivation là-dessus pour s'intéresser au sujet, de voir, tout comme les métriques d'Aura, qui peuvent motiver les équipes, d'autres indicateurs sur du couplage, de la modularité, de la collision de code, etc., de la transférabilité. Ça motive les devs et aussi ça motive, mine de rien, les gens qui sont non tech. Ils comprennent ces enjeux de qualité qui sont vulgarisés. J'encourage toute personne à le faire. C'est un très bon point. Je crois qu'on n'a pas trop parlé, mais de quelle visibilité on donne sur ces indicateurs. Effectivement, il y a d'une part les traquer, les avoir quelque part, les calculer. Mais ce qui est très important aussi, c'est de les montrer et que les gens les regardent. À la fois les équipes tech, comme tu le dis, les équipes non tech, mais même des clients. Alors nous, on est sur la prestation de services, donc ils sont particulièrement intéressés par ça. Mais leur montrer, en fait, ça permet de faire aussi de la pédagogie sur pourquoi la qualité est importante pour nos clients.

56:19 Donc c'est un très bon point. Merci Pierre. Merci Pierre. Du coup, on va t'inviter à redescendre du stage. En tout cas, c'était vraiment super intéressant de discuter avec toi. Et on va prendre une dernière question de Victor, qui a en plus de ça continué à parler avec toi, Thomas, je le vois dans le chat. Est-ce qu'on peut avoir des exemples de questions pour l'entrée? Yes, bien sûr, j'ai répondu à Victor. Je vous ai envoyé le lien de l'exercice, donc c'est inspiré pour créer cet entretien. Donc on a fait toute pièce, on n'utilise pas de solution qui existe, parce qu'on n'a pas trouvé tout simplement. Je serais ravi de discuter avec vous sur LinkedIn, sur Slack, et si vous êtes sur la communauté Tech.Rocks, de cet entretien. Une des questions que j'aime bien poser auprès des développeurs, plutôt sur la partie code, c'est une question ouverte, qui est plutôt de demander qu'est-ce qu'ils valorisent dans le code quand ils écrivent? Quels sont les éléments particuliers auxquels ils font attention? Et du coup, ça permet de voir notamment à quels aspects, on va dire, qualitatifs du code ils font attention ou s'ils vont plutôt privilégier la vitesse.

57:29 C'est souvent ça peut mener sur une discussion, une thématique autour de la qualité et de voir un petit peu quelle attente ou quelle exigence le candidat peut avoir par rapport à ça. Pour compléter là-dessus, moi, par exemple, une des questions que vraiment j'adore poser aux développeurs qu'on voit en entretien, c'est comment ils font pour gérer soit les tickets support, soit les incidents. Et généralement, c'est vraiment un super bon indicateur qui me permet de savoir s'ils ont directement cette vision d'amélioration continue et cette sensibilité au test ou pas du tout. Parce que la réponse, on va dire facile, ça va être toujours régler le problème et c'est tout. Alors qu'en fait, généralement, on va plutôt chercher qu'est-ce qui se passe une fois qu'on a réglé le problème. Et s'ils ont les automatismes de se dire, une fois que j'ai réglé le problème, je dois mettre les tests, je regarde si j'ai des tests, si j'ai bien des indicateurs pour monitorer, si demain arrive le problème que je puisse aussi le détecter d'une nouvelle fois. En fait, moi, je trouve que ça, c'est vraiment les bons mindsets, c'est-à-dire qu'ils sont assez seniors pour avoir cet automatisme-là et cette culture d'amélioration continue autour de la qualité.

58:40 Donc voilà, je ne sais pas si nous avons une dernière question. On peut prendre une dernière question si vous avez. Sinon, pas de questions, je pense que notre meet-up va toucher à sa fin et on va pouvoir directement se retrouver. On a une dernière question. Comment trouver le bon équilibre entre le RTFM et le lead time? Très, très bonne question. C'est une bonne question, je pense que je ne l'ai pas craqué. Honnêtement, je ne sais pas. Je pense qu'il faut le tester et essayer des choses qui s'affinent avec le temps. C'est avant tout continuer à faire de l'amélioration continue, donc mettre en place la méthode et puis regarder comment ça évolue et ajuster en fonction de notre contexte, notre environnement. Je pense que Florian l'a expliqué, il faut avoir sa stratégie qualité et ça dépend de chaque entreprise.

59:40 Je ne sais pas si Florian, tu veux rajouter quelque chose là-dessus? Pas forcément, surtout que j'ai plutôt l'impression que ce n'est pas une question d'équilibre et que le race de first time va avoir tendance à descendre ton lead time. Um, Il y a peut-être quelque chose que j'ai raté dans la question. Alexis, qu'est-ce que tu entends par lead time ? Peut-être que ça nous aidera à mieux répondre. Le lead time, c'est du moment de la spécification jusqu'à la mise en production. Et donc, si je comprends bien la question, c'est que du coup, si en fait, on ne le fait pas right the first time, en fait, on va osciller plusieurs fois. Et à quel moment on va s'arrêter pour ne pas remplisser le lead time qui va être obligatoirement impacté? Et je trouve que c'est vraiment super intéressant parce que moi, je pense qu'il faut toujours se dire, en fait, comment on aurait pu trouver, donc do it right the first time et trouver ça the first time.

1:00:42 C'est ça, en fait, qui va faire que le lead time ne sera à la fin pas impacté. Parce que si on a très, très bien fait nos spécifications et qu'on a pris le temps qu'il fallait pour faire nos spécifications, on saurait poser les bonnes questions. Et donc, en fait, le développeur, dès qu'il va faire son développement, il va trouver les problèmes, il va faire tout bien du premier moment parce qu'en fait, il a déjà super bien clarifié dans sa tête ce qu'il fallait faire. Et donc, obligatoirement, son lead time sera bon. Par contre, si en fait, les spécifications ont été ratées, et bien en fait, do it right the first time, il va devoir itérer énormément de fois dessus. Et donc, obligatoirement, il va impacter négativement le lead time. Et donc, ce qu'on dit entre les lignes, c'est qu'il va falloir très, très bien spécifier pour pouvoir faire do it right the first time. Voilà, si je veux, je... Je crois que j'ai compris la question. C'est l'équilibre entre le temps à passer à faire des spécifications, le temps à passer à réfléchir, et l'équilibre entre faire quelque chose et aller en prod.

1:01:44 Est-ce que c'est ça l'intérêt de ta question, Alexis? Oui, effectivement. L'image qu'on m'avait donnée une fois, c'était de se forcer à fixer des jalons business. Si je fais une plateforme de e-commerce, soit je peux me dire, en fait, je vais faire toute ma plateforme avec tout mon inventaire et qui va avoir de l'authentification, des systèmes d'authentification, etc. Donc, je vais faire tout mon système et puis je ne vais pas mettre en prod avant et je ne vais pas faire de test avant. Je vais mettre un mois à le faire. Ou alors, je peux me dire, dans un mois, je vais pouvoir sur ma plateforme commander, je ne sais pas, une cagette de tomates. Et du coup, ça me fait penser à une conférence TED de comment ne pas faire pour procrastiner. C'est ça, il faut se fixer des jalons et se forcer à avoir des deadlines, même si elles sont assez imaginaires, pour à un moment être pragmatique et se dire, bon, ok, tout n'est pas parfait, mais j'y vais, je fonce.

1:02:57 Et surtout, moi je rajouterais que... Il ne faut jamais prendre une KPI toute seule, isolée dans le temps. Si on parle par exemple de lead time et que de lead time, en fait, ce n'est peut-être pas la meilleure approche d'avoir ça. Et d'ailleurs, j'ai eu une question assez intéressante il y a quelques semaines avec mon CTO qui m'a dit, Farah, on veut augmenter le lead time et en fait, on veut décroître le temps qui est mis sur les incidents. Et est-ce que c'est bon en termes de KPI? Et je lui ai dit, mais en fait, il y a quelque chose de bizarre dans cette réflexion. Il me dit, Farah, c'est quoi? Je lui dis, si en fait, on augmente le lead time, donc obligatoirement, on va être super bon sur notre résolution d'incident parce qu'en fait, il suffit juste de les détecter, bien sûr, qui est en elle-même une difficulté, mais en réalité, dès qu'on les a détectés, on est super bon sur leur résolution. Donc, on va augmenter notre lead time, il va être super faible et notre time de résolution également. Par contre, est-ce que c'est très grave d'avoir énormément d'incidents qui sont courts dans le temps ou est-ce que c'est très grave d'avoir un seul incident qui est très long dans le temps?

1:04:08 En fait, c'est quoi le plus grave des deux? Et il m'a dit, j'aimerais bien savoir. Je lui ai dit, en fait, pour moi, les deux, c'est pareil. Soit on a énormément d'incidents qui sont super courts parce que notre lead time, en fait, il est bon. Mais en fait, en réalité, ce qu'on passe comme message à nos utilisateurs, c'est que notre plateforme, elle n'est pas assez stable. Et donc, nos équipes aussi passent énormément de temps à régler. les problèmes parce qu'ils ne les ont pas anticipés. Soit on va avoir des problèmes qui vont être pas souvent, mais qui vont être assez lents dans le temps. Et pareil, ça va toucher à notre image parce qu'on va faire des incidents où on va avoir beaucoup de choses qui vont être indisponibles. Et donc, du coup, notre fiabilité, elle va être en jeu. Et donc, c'est pour ça, je pense qu'en réalité, la question, surtout sur le« do it right», le« first time right», et surtout sur l'anticipation. Comment on peut anticiper au maximum? voir le minimum de problèmes à la fin et réduire ce temps de lead time, réduire le temps qu'on passe sur les itérations parce qu'on s'est posé les bonnes questions dès le début.

1:05:12 Et pour moi, la qualité, pour être honnête avec vous, c'est ça. Ce n'est pas autant le test, parce que le test, clairement, il est là, il va nous aider à nous améliorer. Mais il faut surtout se poser les bonnes questions dès le départ. Et une fois qu'on est en production, être en capacité de désobserver de ce qui se passe. Voilà, donc j'espère Alexis qu'on t'a répondu à la question. On a fait une longue réponse avec Thomas. Voilà, il est 13h09. Je pense qu'on peut aller sur la salle d'après, du coup, pour discuter, si vous voulez. N'hésitez pas, en tout cas, de rester. Comme ça, on pourra discuter autour des tables dans la salle d'après. Et puis, merci beaucoup, en tout cas, à Thomas et Florian. C'était un plaisir de faire un meet-up avec vous et à Tech.Rocks et à tous les organisateurs de nous avoir hostés aujourd'hui. Merci Farah. Merci à toi Farah. Merci à vous.