- Speaker #0
Bonjour à tous et bienvenue dans les chroniques du design. Je suis Nicolas Guy, designer et cofondateur de l'agence conseil Frontguise. Frontguise est une agence conseil spécialisée en product design et en développement front. Dans cette série de podcasts, nous plongeons dans le témoignage de professionnels qui font le design d'aujourd'hui et découvrons comment elles ont triomphé de leurs échecs et surmonté les difficultés pour en sortir grandis. Aujourd'hui, pour ce nouveau numéro, nous rencontrons Laurent Thibault.
- Speaker #1
Bonjour Laurent. Salut.
- Speaker #0
Comment vas-tu ?
- Speaker #1
Bah écoute, ça va et toi ? Merci de m'avoir invité, c'est super sympa, je suis ravi d'être ici pour le deuxième épisode de ce podcast.
- Speaker #0
Eh bah parfait, merci beaucoup, nous aussi on est ravis de t'entendre, merci beaucoup de prendre du temps pour échanger avec nous. Est-ce que tu peux te présenter rapidement pour ceux qui ne te connaîtraient pas encore ?
- Speaker #1
Yes, bien sûr. Salut tout le monde, moi je suis Laurent Thiebaud, j'ai 29 ans et je suis Engineering Manager chez Decathlon. Je travaille dans l'équipe Design System. Vous l'avez peut-être déjà vu sur internet, il s'appelle Vitamine. En ce moment, on a une nouvelle implémentation en InnerSource dont malheureusement je ne peux pas donner les détails pour le moment, qui est basée sur les Design Tokens, etc. Donc d'autres principes. Et donc moi je suis Technical Leader, c'est-à-dire que j'ai une équipe aujourd'hui de trois développeurs, quelqu'un sur Android, quelqu'un sur la plateforme Apple et quelqu'un sur la plateforme Web. Et côté Web, on supporte plusieurs technologies, notamment React, Svelte et Vue.js. Et donc sur le côté, je suis créateur de contenu aussi dans la thématique du design system, du product design, du design d'interface, de l'engineering, de la tech, un petit peu de business aussi. J'ai notamment une newsletter qui s'appelle Webrunners. que j'essaie de tenir à peu près une fois par mois, qui a aujourd'hui plus de 220 abonnés. Je publie aussi régulièrement sur LinkedIn. J'ai quelques projets en open source, notamment un plugin Figma qui permet de récupérer toutes les variables que j'avais sorties assez rapidement, que Figma sorte sa feature aussi. Donc je suis un passionné par la tech et c'est pour ça que je suis aussi ravi d'être ici parce que j'écoute beaucoup de podcasts, ça me nourrit au quotidien. Je lis pas mal de livres quand je peux, plutôt l'été surtout, quand je suis en vacances, etc. Je n'hésite pas. et donc j'ai hâte de découvrir aussi d'autres épisodes dans ce podcast que je trouve très intéressant sur la thématique des échecs
- Speaker #0
Parfait, merci beaucoup pour cette belle présentation J'ai envie de te dire, quand j'entends tout ça Est-ce que tes journées à toi, elles font 48 heures ? Ou qu'est-ce qu'il se passe ?
- Speaker #1
Très belle question, effectivement Oui, à côté, je suis passionné de musique J'ai aussi une famille, je suis marié J'ai deux enfants, deux petites filles de 3 ans et un an et demi Vie chargée, vie rythmée Mais c'est un petit peu mon profil Je n'aime pas m'ennuyer Je suis passionné... Au travail, je ne le sens pas vraiment comme une forte fatigue. Et puis, je suis aussi un grand passionné de productivité, d'outils. Et donc, j'essaie toujours de trouver des méthodes qui font que, au lieu de passer quatre heures, je vais essayer de tout faire en une heure. Je vais essayer d'avoir une forte culture de l'écrit plutôt qu'essayer de mettre des meetings à chaque fois. Je vais essayer de trouver des méthodes qui peuvent m'accélérer au maximum. Utiliser des outils qui m'aident pour tout ça. Utiliser des techniques aussi de productivité. le pomodoro, le fait de faire des pauses régulièrement, le fait de faire des fois des micro-sieces, etc. Tout ça, c'est des bonnes pratiques qu'il faut qu'au bout d'un moment, avec de la régularité, on gagne en efficience. Mais maintenant, je sais que le chemin n'est pas forcément simple et moi, j'ai encore beaucoup de failles aussi là-dessus. Il y a des périodes où j'ai peut-être été trop loin et après, je ressens des gros coups de fatigue. Mais voilà, l'idée c'est toujours de se relever et de voir qu'est-ce qu'on peut enlever dans notre quotidien, qu'est-ce qui ne fait plus sens, savoir dire non aussi, essayer d'enlever des éléments pour toujours rester au top. Et aussi c'est important je pense de régulièrement faire un petit bilan aussi sur nous-mêmes, peut-être par exemple chaque fin de mois, faire un petit coup de rétroviseur et de regarder ce qu'on a fait et peut-être se dire ça je vais moins le faire puisque... Finalement, c'était un gros effort pour un faible impact. Et quand j'entends impact, je parle d'impact sur ma vie, sur moi-même. Et du coup, ça inclut bien sûr mes missions au sein de l'entreprise dans laquelle je travaille, mais également au sein de ma vie personnelle. C'est toujours une histoire de balance, mais c'est important aussi de regarder chaque mois. C'est pour ça que moi, je ne suis pas un grand fan. Par exemple, là, on est début d'année, les résolutions, tout ça, le faire à l'année et pas forcément regarder en arrière, mais tout de suite redire. Bon là, dès le 1er janvier, je me lance là-dessus. Moi, je suis plutôt dans l'inverse. En chaque fin de mois, regarder un petit peu ce que j'ai fait et pour le mois suivant, voir qu'est-ce que je peux mettre de côté et sur quoi d'autre je peux mettre l'accent.
- Speaker #0
Oui, donc ça passe beaucoup par l'optimisation des process et de la communication et de la productivité.
- Speaker #1
C'est ça, oui.
- Speaker #0
Hyper bien, hyper intéressant. Alors, très bien, merci en tout cas beaucoup pour cette belle présentation. On va rentrer dans le dur du sujet. Donc du coup, de quel échec tu vas nous parler aujourd'hui ?
- Speaker #1
Alors, je vais vous parler d'un échec dans mes débuts de la gestion du design system, parce qu'en fait, je l'ai cofondé avec différentes personnes, dont certaines qui sont encore là dans l'équipe aujourd'hui. On l'a cofondé en fait en 2020, en sortie de Covid. On l'a vendu vraiment bottom-up dans l'entreprise, en posant les problèmes sur la consistance de notre écosystème chez Decathlon. Des problèmes sur l'efficience aussi, le fait que beaucoup de personnes auraient recommencé à chaque fois les mêmes interfaces, les mêmes composants, et d'ailleurs ces interfaces, comme je le disais, elles n'étaient pas forcément cohérentes. Et puis des problèmes d'accessibilité, même si on savait qu'un design system n'allait pas tous les réparer, on savait quand même que c'était un levier sur pas mal d'aspects, notamment la gestion des contrastes, la gestion du clavier, les guidelines qui poussent le fait de ne pas oublier certains attributs quand on consomme des composants, etc. Tout ça c'était nos leviers, on a été le vendre Et donc moi par contre Maintenant quand je fais un petit rétro-pédalage Sur mes débuts dans la gestion du design system Mon échec selon moi en tant que personne qui l'a co-managé Ça a été d'avoir souvent été focus sur des outputs A la place des outcomes Et je vais vous expliquer un petit peu Pour ceux qui ne savent pas vraiment la différence Ce que c'est
- Speaker #0
Yes j'allais te demander la petite idée justement
- Speaker #1
Yes, merci ! Du coup, un output, ça va vraiment être un indicateur qui indique plutôt quelque chose qui vient d'être produit. Par exemple, dans un design system, ça va être des éléments concrets qui ont été créés. Par exemple, un nombre de composants. On a fait une bibliothèque de style. On a fait des directives sur la conception. C'est un résultat tangible sur lequel moi, à l'époque, dès le début, je me suis drivé là-dessus. Je me suis dit, il faut qu'on fasse 10 composants. Il faut qu'on fasse absolument... Une librairie React, il faut absolument faire ça. Il faut essayer aussi d'avoir, par exemple, 10 contributeurs. Et si j'ai tout ça, j'ai réussi mon trimestre, et le trimestre d'après, pareil, c'était très output, output. Et pourtant, dans l'équipe, j'avais encore aujourd'hui Sabrina Vigil, qui pour le coup, elle est design lead du design system, et qui elle était très forte dans l'aspect, va plutôt chercher des outcomes. Et malgré ça, franchement, j'ai mis longtemps à me sortir de la tête de vouloir absolument viser des résultats tangibles comme ça. Et je vais vous expliquer pourquoi les outcomes, c'est mieux. Donc les outcomes, selon moi, c'est mieux parce qu'en fait, un outcome par rapport à un output qui est vraiment un résultat tangible, très clair, un nombre de composants, etc. Un outcome, ça va se concentrer sur l'impact réel. qu'à l'utilisation d'un design system de l'autre côté. Vraiment, la personne qui le consomme, voire même aller jusqu'au client final, grâce au design system, quel impact on a ? Donc, on va vraiment derrière l'output d'avoir sorti 10 composants. Oui, c'est bien, mais est-ce qu'en fait, ça a eu un impact ? En fait, on ne sait pas. Il faut vraiment aller chercher des outcomes. Et par exemple, des idées d'outcomes dans le contexte d'un design system, ça peut être... de mesurer la cohérence visuelle à travers toutes les applications. Donc il y a des entreprises par exemple qui mettent en place un brand index, donc par différentes méthodes de mesure, la plupart ça va être des interviews directement des utilisateurs, soit en magasin, sur leur pratique sportive dans le cadre de Décathlon, du coup j'explique un petit peu ici, mais ça va être ça, ça va être beaucoup d'interviews, avoir du feedback qualitatif au maximum. pour réussir après avec une formule magique, mais qui ne doit surtout pas bouger au fil du temps, un indicateur qui dirait que là, les personnes, globalement, ne s'y retrouvent pas entre les différentes applications, et qu'au fil du temps, les personnes s'y retrouvent. Et généralement, ça, comme le design system, tout le monde est convaincu que c'est un des aspects qui résout, c'est que ça aura eu de la valeur. Et du coup, je trouve que se driver sur ça, c'est beaucoup plus intéressant. Et j'en ai d'autres. J'en ai un autre d'Outcome, par exemple. Ça peut être... aussi sur la réduction du temps de développement d'une application. Donc pareil, les outcomes, c'est des données qui sont très difficiles à maîtriser. Mais ce qui compte, ce n'est pas forcément la valeur à l'instant T. Je trouve que c'est la tendance sur plusieurs mois et plusieurs années. Si on a une tendance à réduire, puisqu'en fait, on a été recueillir des verbatims sur toujours le même questionnaire, mais pendant deux ans, si on arrive à avoir une tendance qui montre que les développeurs, par exemple, sont de plus en plus satisfaits, ça veut dire qu'on réussit. Et pour ça, du coup... On peut utiliser des surveys sur la développeur expérience, que pensez-vous quand vous récupérez une librairie, est-ce que la documentation est claire, etc. Tout ça, on peut notamment des fois le mesurer dans un système NPS, par exemple Net Promoter Score, qui permet de voir s'il y a plutôt des détracteurs sur une autre échelle et de se dire que notre NPS commence à être de mieux en mieux, donc on monte la satisfaction. C'est plus me driver là-dessus. Franchement, j'ai mis au moins deux ans à prendre conscience qu'en fait... quand on se drive là-dessus, finalement, on peut après aller négocier des outputs. Mais les outputs, ils doivent découler pour moi de ces aspects-là. Et voilà un petit peu. Et dans l'engineering, il y a une méthode qui monte pas mal et que j'aime beaucoup, c'est la méthode Accelerate. C'est comment, en fait, on peut... dans un contexte de développement agile, aller de plus en plus vite à sortir des choses, mais aussi tout en restant stable. C'est vraiment la balance entre la vélocité et la stabilité. Vous pouvez aller voir, en fait, dans la méthode Accelerate, il y a notamment quatre métriques qui sont intéressantes. Elles s'appellent les Doramétrics. La première, c'est une partie sur la vélocité. Il y en a deux. On peut par exemple mesurer la fréquence de déploiement, parce qu'en fait, c'est sûr que si on déploie fréquemment, ça crée de la satisfaction, ça crée du coup, ça crée que s'il y a un problème, on peut vite réagir, etc. Donc la deployment frequency. Également le lead time pour des changements, ça c'est intéressant de le traquer. Donc à partir du moment où vous ouvrez une issue, En combien de temps elle a été close ? Ça, ça peut être intéressant, parce que du coup, si c'est long, c'est là où, par exemple, nous on a un checkpoint tous les mois avec notre direction, le design system, c'est là où on peut dire que si c'est long, c'est probablement soit parce qu'on n'est pas assez dans l'équipe, soit parce qu'on n'a pas les bons outils, mais en tout cas, on peut creuser pour comprendre pourquoi c'est long, mais cet indicateur, il est vraiment hyper important, parce que si on met 8 jours à changer la couleur d'un bouton, c'est potentiellement que dans la chaîne, il y a un souci, peut-être qu'il n'y a pas assez de disponibilité des designers. Peut-être qu'avoir un développeur à 10%, ce n'est pas une bonne idée. Et là, on revient par exemple à mon aspect d'avant où j'allais chercher des contributeurs à 10%. Moi, j'étais content à l'époque. Mais en fait, peut-être que la DoraMetrics, elle m'aurait dit Mais du coup, tu mets 8 jours à changer la couleur d'un bouton, est-ce que c'est bien ? Et donc, c'est pour ça que je préfère maintenant me driver sur ça. Et la deuxième partie, donc il y avait Vélocité. La deuxième partie, c'est sur la stabilité du système. Le Change Failure Rate. Donc ça, c'est est-ce que quand vous faites un changement ça crée d'autres bugs. Donc là, il faut essayer de le maintenir le plus bas possible. Donc là, c'est notamment sur l'aspect de stabilité, parce qu'on ne va pas non plus trop vite, et du coup, on fait pire que mieux. Donc ça, c'est un peu notre aspect. Et le Median Time to Restore, c'est en combien de temps on a restauré. Donc ça, c'est plutôt sur la mise en prod, en fait. Par exemple, côté Design System, à partir du moment où on merge quelque chose côté design, que c'est retranscrit dans les tokens, qu'ensuite qu'on remerge cette branche, que ça part côté développeur, qu'on fait le changement, qu'on merge, en combien de temps on a réussi, à partir du moment où on a fini le changement, à mettre en prod ? Et nous, chez Decathlon, on est à peu près autour de 10 minutes. donc ça c'est ce genre de truc qu'il faut, je pense, en tout cas moi ce que je vous conseille c'est un conseil de quelqu'un qui s'est raté après deux ans qui s'en rend compte maintenant, même trois du coup, bah ouais en fait ça fait trois ans, maintenant voilà je me drive plus là-dessus et juste pour info si je suis arrivé là-dessus c'est beaucoup grâce à mes collègues et grâce à toutes les personnes qui nous ont rejoints depuis le temps, parce qu'en fait je me suis nourri d'eux et je ne l'ai pas trouvé par moi-même pour le coup autant j'écoute pas mal de podcasts je lis pas mal de livres Mais celui-là, ça a été beaucoup des gens de l'entreprise Decathlon qui me l'ont dit, en fait. Et après, j'ai écouté, je me suis dit, ah ouais, effectivement, vous avez raison.
- Speaker #0
Ça me rappelle une des valeurs fortes de FrontGay, c'est le partage de connaissances. Tout simplement, je veux dire que ce soit en interne ou en externe, c'est quand même la meilleure façon d'avancer et d'évoluer. Merci pour ça. Est-ce que j'aimerais bien revenir justement sur l'échec en lui-même, qui n'est pas un échec ponctuel, c'est plutôt quelque chose que tu faisais dans le temps et qui a évolué dans le temps. Est-ce que tu pourrais éventuellement me parler de quelques conséquences que ça a eues, des conséquences néfastes, que ce soit... Sur l'opérationnel, sur éventuellement le moral des équipes, ou même ton moral, ou même une question de confiance, en termes de conséquences, qu'est-ce que ça a apporté ?
- Speaker #1
Ça a apporté à certains moments par exemple un team mood, donc une forme de l'équipe qui est descendue. Par exemple, quand j'étais driver sur Output, le problème c'est qu'on ne prenait pas en compte pas mal de choses. Par exemple, il faut avoir 10 composants, si on arrive à 5, le problème c'est que ça ne met pas en lumière où était le problème. Et moi comme je drive une équipe développeur, peut-être qu'on peut se dire du coup c'est le bout de chaîne, mais non pas forcément, et des fois ça vient même pas de la faute de l'équipe, c'est peut-être le contexte qui fait que finalement on s'était drive sur des contributeurs, mais finalement comme ils sont déjà bien dans Antidate ici, là ils n'avaient pas réussi à se libérer et du coup on n'a pas bénéficié de review, mais comme on s'était dit en équipe qu'on ne pouvait pas merger sans avoir une review, du coup les composants n'ont pas été mergés, ce qui a décalé de 2-3 semaines et en fait on n'a pas réussi. Donc ça, ça a été un des premiers impacts. Ça a été que du coup, forcément, l'équipe, après, on commence à être de plus en plus un peu triste, en fait, de cette situation, de se dire mais on ne comprend pas. Et donc, le fait du coup de prendre d'autres indicateurs maintenant met une lumière beaucoup plus claire sur où est le problème, en fait. Et du coup, nativement, on est moins triste facilement, puisque ce n'était pas juste atteindre un nombre qui, finalement, ce n'est pas forcément ça. L'intérêt principal, c'est plutôt atteindre qu'est-ce qu'on va avoir comme impact. Et généralement, grâce à ces indicateurs-là, on arrive tout de suite à comprendre très vite d'où vient le problème. Et des fois, il ne vient pas forcément de l'équipe. Mais c'est à nous en équipe, en tant que responsable du design system, d'aller chercher là où il y a les problèmes et de les remonter pour essayer que ça n'en soit plus le mois d'après.
- Speaker #0
Oui, bien sûr. Et donc, toi, en tant que manager, quand tu vois justement... Le moral des équipes en baisse, dû du coup un peu à des décisions d'équipe de management de la direction. Quel genre d'action ? Si on rentre plutôt dans l'aspect relationnel que tu as avec tes équipes, parce qu'au final, quand on a des équipes qui sont démoralisées, enfin, démoralisées, ce n'était peut-être pas le terme, c'était peut-être trop fort, un peu triste ou qui perdent confiance. Humainement, qu'est-ce que tu vas essayer de leur apporter ? pour justement faire en sorte qu'ils remontent sur le cheval et qu'ils avancent.
- Speaker #1
Oui. Du coup, déjà, dans mon management, j'ai une approche vraiment très centrée sur l'humain. J'essaie vraiment de créer à chaque fois une atmosphère très positive, collaborative. Moi, ma résilience, ma discipline dans mon travail que j'ai cultivée notamment grâce à mes passions, en fait, elles se traduisent directement dans mon leadership. C'est vraiment ce que j'essaie de faire. Donc, j'essaie de créer un environnement positif. Donc, ce que je vais faire, par exemple, Déjà, j'essaie tout de suite de détecter des signaux faibles, parce que malheureusement, des fois, un team mood, ça ne suffit pas juste de demander si ça va. Et je pense qu'un bon manager, c'est quelqu'un qui va vite se rendre compte que ça ne va pas. Donc moi, j'essaie vraiment d'avoir une approche proactive. On est globalement très souvent en remote, parce que j'ai une personne dans l'équipe qui est à Nantes, une personne dans l'équipe qui est à Paris, maintenant on a quelqu'un dans l'équipe qui est à Amsterdam aussi. On arrive avec la barrière de la langue aussi, où maintenant on parle entièrement en anglais, mais du coup c'est un exercice qui n'est pas évident, encore plus difficile de dire que ça ne va pas quand ce n'est pas dans la langue maternelle. Et donc moi mon approche c'est de vraiment essayer de rencontrer les gens souvent en visioconférence, même juste 2-3 minutes, pour vraiment prendre un petit peu la température, comment ça va, et puis si je vois un signal faible qui me fait dire que là ça ne va pas, J'essaie tout de suite de comprendre en fait. Donc là, ce que je vais faire, c'est que là, je programme plutôt une visio de un quart d'heure, 20 minutes. En disant là, est-ce qu'on peut essayer de parler de tel point ? Comment tu l'as vécu ? Cette décision qu'on a eue collégialement, j'ai vu que tu as essayé d'apporter ton idée, mais j'ai vu que ça n'a pas pris et après, je t'ai senti triste. Est-ce que tu veux qu'on en parle ? Vraiment, j'essaie de faire ça. Et à partir du moment où je fais ça, généralement la personne se livre. Donc je crée le contexte pour qu'elle me dise les choses et je lui fais comprendre qu'il n'y a aucun souci, on peut tous dire. Et au moment où elle me dit les choses, ou il me dit les choses, on arrive sur, là je prends un plan d'action. Donc si c'est quelque chose qui concerne plusieurs personnes de l'équipe, du coup on va se voir en équipe et on va faire un point dédié à ce qui vient de se passer sur ça, tout en restant positif. Et en tout cas, j'essaie de craquer au plus vite et détecter au plus vite aussi.
- Speaker #0
Ok. Et toi, du coup, quand tu as des choses comme ça qui se passent, où là, c'est dans cette situation, j'imagine que c'est un peu l'ensemble de l'équipe qui était un peu en bad mood. Toi, personnellement, c'est des choses, j'imagine que si tu as un management humain et bienveillant comme ça, j'imagine que ça doit te toucher aussi forcément personnellement. Donc, comment tu arrives justement à… Garder le cas par te redresser. On dit souvent que si nous-mêmes, on est dans une ambiance un peu bad mood, on a tendance à la transmettre. Du coup, il faut essayer de rester dans cette ambiance good mood et positive. Comment tu arrives à manager ça de ton côté ?
- Speaker #1
La réponse, c'est déjà que des fois, je n'arrive pas. Je fais des erreurs. Non, mais on arrive sur encore des échecs, encore récemment. Moi, ça m'arrive des fois de faire transparaître un stress que j'ai. Et donc, moi-même, constamment, j'essaie déjà de me remettre en question. Et en fait, quand vraiment ça arrive vers moi, maintenant, j'essaie vraiment de ne pas le montrer et d'aller rapidement, peut-être si j'ai besoin, en tout cas, en parler à mon propre manager, qui pour le coup est un dear of engineering. Thomas qui a beaucoup d'expérience, a beaucoup de recul et du coup lui il arrive régulièrement à me remettre sur le bon rail, à me donner les bons conseils très rapidement. Donc j'ai cette chance en fait qu'au-dessus de moi, j'ai quelqu'un qui peut tout de suite me coacher et qui est aussi très humain. Donc ça je trouve que c'est hyper important parce que si je n'avais pas au-dessus quelqu'un qui parlait effectivement, Je pense que du coup, s'il y a des auditeurs qui sont peut-être dans cette situation, alors j'essaierai d'aller trouver un mentor dans l'entreprise ailleurs. Mais quelqu'un qui a plus d'expérience que moi, quelqu'un qui a plus de vécu, qui a vécu des situations difficiles, pour vraiment me faire relativiser et me donner les bons conseils pour voir comment je peux adapter une situation qui vient de se passer.
- Speaker #0
Parce que du coup, est-ce que ce ne serait pas ça le secret, justement, réussir à faire relativiser ? Parce qu'au final, oui, certes, il y a des... Des investissements forts, il y a des objectifs, etc. Mais mine de rien, est-ce que ça vaut le coup de se mettre, comme disait ma grand-mère, la rate au courbouillon, pour des problématiques qui n'en sont peut-être pas ? Est-ce que le secret, ce n'est pas justement de relativiser, de réussir à prendre du recul pour pouvoir replonger et avancer ?
- Speaker #1
c'est ça et des fois il arrive des choses dans la vie il suffit de regarder les infos il suffit de regarder des fois malheureusement quand il se passe aussi des tristes nouvelles des décès etc c'est ces petites périodes là qui font prendre conscience que moi dans mon cas en tout cas je travaille sur un design system et que voilà c'est pas parce qu'on a une journée de retard que ça y est c'est la fin du monde et qu'il faut se mettre dans le rouge on est dans un marathon On ne peut pas être 100% productif chaque jour. Ce qu'il faut faire, c'est prendre soin des personnes pour qu'elles soient au meilleur d'elles-mêmes, qu'elles grandissent. Et que si on prend vraiment une photo plutôt au trimestre, voire au semestre ou à l'année, ça avance en fait. Mais à la journée, moi je ne suis vraiment pas un manager qui manage à la journée. Parce qu'une journée, c'est tellement différent d'un jour à l'autre en fait. On peut avoir quelqu'un qui va nous sortir le feu le lundi et le mardi, ça ne va pas du tout aller. Mais en fait, pas grave. Moi, tant que sur le trimestre, on a les outcomes et que ça grandit au niveau KPI ou que ça réduit si on doit réduire, moi, ça me va en fait. Et j'essaie vraiment que les gens soient heureux au travail au maximum parce que je suis sûr que c'est comme ça qu'à la fois qu'on les garde et qu'on les fait grandir et qu'ils ont des bonnes performances.
- Speaker #0
Très beau, magnifique, je suis totalement aligné avec cette vision des choses, le point de vue vraiment humain et bienveillant pour moi, c'est vraiment crucial dans la partie management, mais aussi bien management qu'opérationnel, et effectivement, alors il y a un truc que tu me dis, quand tu me dis, déjà j'y arrive pas tout le temps quand je suis stressé ou triste, de ne pas le faire transparaître, et tu me dis, j'essaye de ne pas le faire transparaître, et... J'ai l'impression que dans le monde des entreprises, quand on est à un poste à responsabilité, manager, etc., en fait on n'a pas le droit d'avoir des coups de mou et que du coup c'est mal vu et que ça peut entraîner d'autres conséquences, alors qu'on est tous humains. et qu'on a le droit normalement d'avoir ces coups de mou, ces petits manques de confiance. Et ça revient un petit peu justement à quelque chose qui est très présent dans le design, qui est le syndrome de l'imposteur, de se sentir pas légitime à notre place, notamment quand on subit des échecs et des choses comme ça. Qu'est-ce que tu penses de cette réflexion ? Est-ce que tu penses que c'est vraiment quelque chose à ne pas montrer, à cacher absolument ? Ou est-ce que tu rêves d'une entreprise où même à ces postes-là, on a le droit d'avoir ces périodes-là qui sont un peu compliquées à gérer ?
- Speaker #1
Non, je pense qu'on... En tout cas, par exemple, chez Decathlon, le droit à l'erreur, c'est quelque chose qu'on apprend dès le départ quand on est onboardé. On est onboardé dans une entreprise où on a le droit à l'erreur. De base, on nous explique que c'est comme ça que vous allez oser faire des choses. Parce que si tu arrives dans un contexte où tu n'as pas le droit à l'erreur, tu es moins innovant, tu es moins créatif. Peut-être que le design system, on n'aurait jamais osé le lancer en bottom-up parce que si on n'avait pas le droit à l'erreur, ce que j'aurais osé... Il y a trois ans, avec Sabrina, avec Marie, avec Ronan, aller voir le CTO, si on n'avait pas le droit à l'erreur, non, je n'aurais peut-être pas osé, parce que j'ai un CDI, j'ai envie de rester, je m'y sors bien. Là, non, t'arrives, t'as le droit à l'erreur. Bien sûr, on traque régulièrement, on te remet sur le droit chemin, on arrête ton projet si vraiment il n'y a pas les résultats, mais t'as le droit à l'erreur, en fait. Et après, tu pourras refaire une autre après, tant que c'est pas... 20 fois la même quoi, mais t'as le droit. Et donc ça, non, non, moi je suis vraiment pour cet aspect-là, puisque c'est notamment pour ça que je suis chez Decathlon aussi, parce que j'aime beaucoup cet aspect qui prône la créativité au travail et l'innovation. Par contre, il y a vraiment un point où moi j'essaie vraiment de faire très attention et je me goure encore, et c'est vraiment pour mon équipe. Quand il y a des choses qui, je sais que ça va leur faire du mal s'ils me voient mal, alors qu'en fait il suffirait juste que je me cache un petit peu et que j'en parle à mon manager. Du coup, ce n'est pas très compliqué pour moi. Ça, il faut vraiment que je me force parce qu'en fait, ou des fois, des discussions qui ne sont pas encore actées, qui m'impactent parce qu'admettons, on ne va pas avoir tel budget ou telle enveloppe qu'on avait voulu pour refaire une librairie ou j'en sais rien, où on va devoir rationaliser une techno vers une seule techno, etc. Tant que ce n'est pas acté, et moi pourtant, en tant que manager, je suis dans ces discussions, je pense que des fois, c'est important de... ...pas tout dire tout de suite parce qu'en fait, ça se trouve, ce sera jamais acté. Donc en fait, il n'y a peut-être pas besoin d'alerter tout de suite. Donc ça, pour le coup, on a le droit à l'erreur, et du coup je fais encore ces erreurs-là, mais j'essaie de ne plus les faire celles-ci, de parler trop vite, etc. Parce que quand tu arrives dans le management, tu arrives dans des discussions où ce n'est pas le fait de ne pas être transparent ou de cacher, c'est juste que ce n'est pas acté, donc ça ne sert à rien peut-être d'alerter pour rien.
- Speaker #0
et de faire peur c'est juste une question de timing au final c'est juste embarquer les gens au moment où ça peut avoir de la valeur pour eux et pas les mettre et pas rester sous les rumeurs les rumeurs en fait dès que c'est une rumeur pour moi il faut faire attention en tant que manager les
- Speaker #1
rumeurs sont difficiles il faut les garder au maximum et pas forcément les répandre trop vite, manager c'est aussi fait pour pas qu'elles se répandent trop tant que c'est une rumeur
- Speaker #0
Tout à fait, parce qu'effectivement, on peut très facilement donner de l'espoir à une équipe, par exemple, une rumeur très positive. Et puis en fait, c'est tentant en tant que manager parce qu'on a envie de leur donner des perspectives, on a envie de leur dire vous inquiétez pas, ça va le faire Et en fait, tant que ce n'est pas acté, effectivement, tu as raison, il vaut mieux le garder pour soi. Et puis, on arrivera, si c'est vraiment acté, là, on leur donnera un vrai espoir et des vraies raisons d'être heureux et épanouis.
- Speaker #1
Ok.
- Speaker #0
C'est un très beau sujet, c'est passionnant tout ça. Un titre par rapport à l'échec dont tu as parlé sur les output, outcome. Aujourd'hui, c'est quelque chose que tu as dépassé, que tu as appris à mettre en place d'un point de vue… Et donc du coup, comment tu en es arrivé là ? Tu me disais tout à l'heure que c'était beaucoup en discutant avec tes collègues, etc. Mais comment tu as réussi à transmettre ça aux équipes du coup ?
- Speaker #1
C'est par le concret. Je trouve que ça, il faut sortir très vite des livres et de la théorie. Parce que quand je vous parle par exemple de Doramétrix, etc., vous êtes dans la théorie, là, si vous écoutez, vous allez peut-être aller regarder. Par contre, quand on en parle aux équipes, il faut bien sûr leur faire la même intro que j'ai faite, mais pour moi, il faut s'arrêter à 10 minutes et tout de suite après l'appliquer au contexte qui parle aux gens. Parce que, et limite arrivé déjà avec le dashboard, avec des fausses données, nous par quoi on a commencé, et c'est très récent, on a fait un petit atelier où en fait on a fait un icebreaker lors de notre lancement d'année là, et on s'est dit dans FigJam, donc il y a un outil de whiteboarding comme Miro comme d'autres, on s'est dit bah on va dessiner notre dashboard et on se met la contrainte de rester en 16 neuvième, comme si on avait une télé toute la journée, et qu'est-ce qu'on allait afficher ? sachant qu'on doit afficher que des outcomes, donc des KPIs de ce type de métrique. On avait donné à dispo une libe de charts, un petit UI kit de charts, donc avec des pie charts, avec des graphes de diverses manières, des numbers, etc. Et chacun a dessiné son petit dashboard, et c'était pas mal, parce qu'après, on avait du coup 10 minutes pour faire ça, et sur les 20 autres minutes, on a tous discuté, et on a créé le dashboard parfait de l'équipe, qui concerne du coup 8 KPIs, qui passe sur une télé, Et donc ça, ça a parlé tout de suite aux gens. Et on s'est refusé de mettre des outputs. Donc avant, on avait bien sûr fait la différence entre les deux. Et voilà, je pense que la meilleure façon de l'amener, c'est d'aller comme ça vers le concret. 15 minutes de théorie, 30 minutes de pratique. Et au bout d'une heure, je pense que tout de suite, les gens vont comprendre qu'effectivement, c'est mieux. C'est mieux de se dire qu'on va augmenter l'efficience, que derrière notre design system, au fur et à mesure, il y a une corrélation entre il est présent et du coup, ça augmente la performance des applications. Ça augmente leur taux d'accessibilité, alors que quand il ne l'est pas, c'est moins haut, ces taux-là. Versus, on doit absolument avoir X contributeurs, 13 composants sur le mois.
- Speaker #0
Voilà, ça, on ne sait pas l'impact que ça a. Ça se trouve, ces composants, ils ne sont pas utilisés. Donc, aussi bien traqué que c'est bien utilisé, etc. Toutes ces données-là, quoi.
- Speaker #1
Ouais, donc du coup, vraiment, effectivement, le concret, moi, je suis totalement d'accord. Effectivement, on n'apprend pas mieux que quand on fait les choses. Et puis, effectivement, cet aspect collaboratif, c'est-à-dire vraiment... Faire s'engager les gens et faire participer les gens à la création de ça pour que derrière, ils aient vraiment une compréhension parfaite de ces outcomes et qu'ils puissent être engagés dessus. Effectivement, pour moi, c'est une très bonne solution. Merci beaucoup, Laurent, pour tout ça. Le temps file. On pourrait continuer à parler pendant des heures. Tu m'avais parlé quand on a commencé à préparer et à discuter ça, d'une éventuelle conclusion où tu voulais parler avec des méthodes OADR, d'architecture, etc. Est-ce que tu veux toujours partager un petit mot sur ça ? Est-ce que tu penses que c'est pertinent par rapport à tout ce qu'on s'est dit ?
- Speaker #0
Carrément, en fait, effectivement, quand on a préparé à deux ce podcast, que moi je découvre du coup sur sa thématique, sur les échecs, et l'impact que ça a sur nos vipros, vipersos, etc., et comment grâce à ces échecs, on devient plus fort. J'ai vraiment adoré l'approche parce que moi, quand je l'ai préparé, pour t'expliquer cet échec, je l'ai fait de manière contexte, problème, solution. Donc forcément quand on explique un échec, généralement on met en place le contexte, donc on était en telle année, les gens revenaient de confinement, enfin c'est un peu ce que, je ne l'ai pas dit comme ça mais je vous ai dit post-covid et tout, contexte remote etc, enfin il y a toujours un contexte, en tout cas il y a toujours un moment auquel on a eu cet échec, et c'est important d'expliquer le contexte pour bien comprendre. Il y a ensuite, du coup, il y a eu un problème. Et après, on a passé la majorité de l'épisode à expliquer la solution pour plus que ce problème se reproduise. Et en fait, j'ai trouvé que ça, ça m'a reflété quelque chose que je fais au quotidien, qui a été poussé beaucoup par l'engineering chez Decathlon, qui est la méthodologie ADR, donc c'est Architecture Decision Records, qui est exactement le même framework, contexte, problème, solution. En fait, c'est une manière de tracer nos décisions à un instant T. dans nos repositories. Donc, clairement, c'est sur GitHub, c'est dans un fichier Markdown, c'est un dossier ADR. Et là, on les liste. Le 1, c'est pourquoi on est parti sur Svelte et pas React. Enfin, c'est un exemple, c'est pas vrai. Après, pourquoi on a utilisé telle librairie pour faire le datpicker ? Pourquoi on a utilisé les data attributes pour faire nos sélecteurs CSS, etc. Vraiment, toutes les décisions, les tracés. Et ça, ça a plein de vertus parce que quand on onboard des nouvelles personnes, on leur dit tu peux regarder le repo, tu peux regarder notre doc et surtout regarde toutes nos décisions. Parce que nous, par exemple, dans nos ADR au Design System, on a plein d'ADR sur comment on nomme les tokens, quels sont les trois niveaux de layer de nos design tokens, quels outils on utilise, sur quoi on est parti pour le naming, sur quelles conventions, etc. Et ça en cross-platform, on en a encore fait un hier où on s'est dit que le problème par exemple si vous faites des design systems Un toggle s'appelle Switch sur Android, il s'appelle toggle sur le web, il s'appelle toggle sur Apple. On s'est dit du coup, sur Figma on garde les noms au plus proche des standards, donc sur Android ça va être Material 3 en ce moment, sur Apple ça va être SwiftUI, sur le web il n'y en a pas, il y a OpenUI quand même, il y a une initiative qui se lance pour essayer de cadrer tout ça, et ça c'est vraiment pas mal, mais sinon il n'y a pas de gros standards malheureusement. et du coup on se rapproche quand même de l'HTML au plus proche dans les namings, si ça existe le composant, et donc là on s'est dit, dans Figma, dans la librairie dev, on prend le même nom, donc pour le toggle, toggle, toggle, côté web, toggle, toggle, côté Apple, et switch, switch, côté Android, par contre pour les tokens, pour éviter d'avoir des noms différents aussi, alors qu'en fait on parle du même univers, alors on a décidé de prendre le nom de la plateforme web. c'est parce que c'est pareil dans les tokens dans nos valeurs on met du css et pourtant une cubic baisiers en css elle s'affiche pas pareil en compose ou en swift et ben on a décidé que c'était le web et ben cette décision il faut la tracer parce que quelqu'un qui arrive dans l'équipe après il va pas comprendre, un dev android il va dire pourquoi ça s'appelle toggle en fait c'est un switch ou alors pourquoi c'est une bottom sheet et c'est pas un drawer pour un développeur web, ben ouais parce qu'on a pas les mêmes jargons, il y a des opinions et donc il faut tracer tout ça et voilà j'ai trouvé que ton podcast en fait j'ai été vite à l'aise à le préparer parce que c'est quelque chose que j'utilise au quotidien et je recommande à tout le monde Et juste pour info, il ne faut pas avoir peur de tracer des décisions, parce que dans les décisions, il y a une date, et la date, elle peut changer. Donc une décision, elle peut être mise à jour, et moi, ça rebondit avec le droit à l'erreur. On peut se tromper dans une décision, mais en tout cas, il faut la tracer, parce qu'on l'en fait tout le temps, et si on ne trace pas, c'est compliqué d'unborder, c'est des fois compliqué de se souvenir aussi. Merci pour ça.
- Speaker #1
De rien, et grand grand plaisir, et c'est vrai que... Dans les profils juniors, moi je rencontre souvent des gens qui se disent Ouais, mais là on va prendre une décision, donc il faut vraiment qu'on soit sûr de nous à 1000% et qu'on essaye de sécuriser les choses à fond. On n'y va Et bien du coup, on n'y va jamais et donc c'est le problème. Et donc voilà, je pense qu'il faut quand même trouver le bon équilibre. Il faut bien étudier les choses pour prendre une décision en connaissance de cause, collaborative, etc. Mais il ne faut pas tergiverser et donc voilà, il faut prendre une décision en sachant que on pourra revenir sur ses décisions et que ce n'est pas grave et qu'il n'y a pas de problème avec ça. Et ça permet d'avancer plus vite, moi, je trouve. Et c'est vrai que je trouve que ça colle vachement plus avec toutes les méthodes de design, d'itération, d'agilité. Et ça, je trouve que c'est très, très fort. Merci beaucoup, beaucoup, en tout cas, Laurent, pour tous ces conseils et ce témoignage. Je pense qu'effectivement, pour moi, le cœur de tout ça, c'est quand même, malgré tout, La bienveillance, l'aspect vraiment humain, motivation, le droit à l'erreur, tout ça, c'est des sujets qui sont vraiment hyper importants. Et quand ils sont vraiment appliqués en entreprise, je pense que c'est là où vraiment on peut faire briller les gens, faire que les gens s'épanouissent vraiment et avancent, donnent le meilleur d'eux-mêmes. Et au final, ça se retrouve dans le produit, ça se retrouve dans le business, ça se retrouve partout. Donc pour moi, c'est vraiment essentiel. Merci beaucoup d'avoir témoigné à travers ce podcast. Est-ce que tu as un petit dernier mot pour la fin ? Avant qu'on se quitte ?
- Speaker #0
Merci à toi de m'avoir invité. Merci d'avoir créé les chroniques du Design Ops. Je trouve que c'est un super podcast. J'espère voir plein d'épisodes par la suite. Ne pas avoir de syndrome de l'imposture là-dessus. C'est super bénéfique dans tous les cas d'écouter des témoignages. Le format de podcast est génial parce que... Qu'est-ce qu'il y a plein de moments, des fois, où on ne peut malheureusement rien faire ? Moi, quand je suis en volant, en voiture, j'écoute bien sûr de la musique, des fois, parce que ça détend aussi de se déconnecter. Mais des fois, j'ai envie d'écouter un podcast. Et ce que j'aime bien dans ce format, c'est que ce n'est pas forcément beaucoup cuté. C'est très naturel, c'est une discussion. Et moi, j'ai vraiment apprécié ça. Et en dernier mot, ce serait un mot pour l'équipe du Design System de Décathlon. leur dire que je suis très fier de tout ce qu'on a fait. Je suis content de la voir grandir au fil des années. Ça fait trois ans qu'à chaque fois, ça fait fois deux. Donc, ça va s'arrêter au bout d'un moment au niveau du nombre dans l'équipe. Mais voilà, je suis très fier de tout ce qu'on fait. Et donc, voilà, c'était un petit mot pour une petite dédicace.
- Speaker #1
Écoute, c'est parfait, c'est gentil, c'est bienveillant. Merci beaucoup, Laurent, pour ta participation. Je te dis au revoir, je te dis bonne continuation. Et puis, je te dis à bientôt.
- Speaker #0
A bientôt, salut !
- Speaker #1
Salut !
