Mathieu Sanchez, Télétravail et travail asynchrone – Pragmatisme et dette technique

Transcription de l'épisode : "Mathieu Sanchez, Télétravail et travail asynchrone – Pragmatisme et dette technique"

Terry : Salut Mathieu.

Mathieu : Salut Terry.

Terry : Merci de me recevoir de nouveau chez ACASI. Aujourd'hui on va parler d'un sujet dont on n'avait pas eu le temps de parler dans les détails lors de notre premier échange qui est le sujet du télétravail, travail asynchrone dans une première partie et deuxième partie on va parler d'un sujet qui touche particulièrement les devs qui est autour du pragmatisme. Donc faire les choses bien versus les faire quick and dirty. Et avant de rentrer dans le vif du sujet, je te propose, pour ceux qui ne te connaissent pas, de te présenter de nouveau et puis de nous présenter ce que vous faites chez ACASI.

Mathieu : Ça marche, merci. Du coup merci de me réinviter. Alors je vais essayer de me présenter un peu différemment de la dernière fois pour s'il y a des gens qui écoutent les deux, on sait jamais. Donc je m'appelle Mathieu, je suis Je suis papa de deux petites filles, dont l'une qui m'est réveillée à 5h du mat' ce matin, donc si à un moment je dis n'importe quoi, tu me fais des signes. Donc moi, mon parcours, j'ai fait une école d'ingénieur, j'ai travaillé chez Air France pendant 6 ans, dans un domaine qui n'était pas le développement web, qui était un peu différent. Recherche opérationnelle, si ça parle à quelqu'un, c'est un mot qui n'explique pas très bien ce qu'on fait, mais je ne vais pas forcément rentrer dedans maintenant. Et ensuite, j'ai travaillé dans une boîte qui faisait un logiciel SaaS de marque blanche pour les VTC. Et il y a deux ans et demi maintenant, je suis arrivé chez ACASI en tant que CTO. Et donc ACASI, qu'est-ce que c'est ? ACASI, c'est à la fois un logiciel et aussi un service, un accompagnement. d'expertise comptable pour les freelancers indépendants. Donc notre mission, on va dire, notre objectif, c'est à la fois de permettre d'avoir une vision sur ta comptabilité en temps réel, donc ça c'est quelque chose qui parfois est un peu compliqué parce qu'aujourd'hui souvent quand tu as un expert comptable classique, tu ne sais, tu connais ton impôt, que à la fin de ton année fiscale, voire six mois plus tard. Avec ACASI, en fait, en temps réel, tu sais combien tu vas payer dans six mois, dans un an, etc. Donc ça, c'est un petit peu le premier objectif. Et le deuxième, c'est de décharger les freelancers de toute cette charge mentale qu'est la comptabilité. Donc notre promesse, un petit peu, c'est que tu n'aies pas à penser à ça, que tu te concentres sur ton cœur de métier, ton business, développer ton activité, et tout ce qui est de la comptabilité, on s'en charge pour toi.

Terry : Ok, très clair. Donc merci pour cette présentation V2, c'est aussi cool d'avoir un peu de nuance sur ça. Donc pour rentrer un peu dans le vif du sujet télétravail et travail asynchrone, je pourrais commencer en disant souvent on oppose le travail en présentiel au télétravail sans nécessairement parler de la notion de travail asynchrone.

Mathieu : Ouais.

Terry : Et on pense plutôt à se dire bah télétravail ça veut dire que je travaille depuis chez moi, mais il n'y a pas spécialement, on va dire dans les croyances communes, la notion de qu'est-ce que ça veut dire que de faire du travail asynchrone, qui peut être fait autant sur site qu'à distance. Donc déjà toi un peu, enfin si on devait, si tu devais un peu donner toi la, pas une définition mais ta vision de qu'est-ce que ça veut dire que le travail asynchrone versus le télétravail tout court, et un peu ta position là-dessus.

Mathieu : Alors du coup, je vais commencer par digresser un peu, en te racontant un petit peu mon expérience là-dessus. Puisque du coup, moi j'ai vécu, je pense, le travail sur site qui ne faisait pas de la synchrone. Donc j'ai vu, si tu veux, en tout cas moi j'ai expérimenté sur du... J'ai bossé, c'est dans mon ancienne boîte, j'ai bossé 5 ans dedans. Et du coup, j'ai vu un petit peu tout l'impact que ça avait de ne pas forcément prendre le temps de... C'est à la fois de faire du travail asynchrone, de ne pas faire du travail asynchrone, mais de ne pas faire, je dirais, de la documentation, de ne pas assez écrire, en fait. C'est ça. Et donc, pour te décrire un petit peu ce qu'on faisait, c'est qu'effectivement, on était toujours sur site. Et donc effectivement, on était tous ensemble. Et ce qui est bien pratique quand t'es tous ensemble, c'est que dès que t'as une question, tu te tapes sur l'épaule, tu vas prendre un café, tu fais une réunion. Si t'es pas forcément bien discipliné, bien organisé, tu fais pas forcément des comptes rendus de réunion, y'a pas forcément quelqu'un qui prend des notes, parce qu'il faut se l'avouer, c'est très pénible de prendre des notes. La plupart du temps, en plus, on sait pas bien le faire, donc c'est difficile de faire des comptes rendus de réunion, je trouve, en tout cas à titre perso. Et donc, on avait ce fonctionnement, qui était d'un côté hyper agile, c'est tu te vois, tu parles, c'est hyper simple. Mais ça a arrivé qu'on parle d'un sujet, finalement on le met de côté, donc on fait une session de brainstorm, on design une fonctionnalité par exemple, on y réfléchit beaucoup. Et puis il se passe trois mois parce que d'autres priorités, donc on travaille pas dessus. Et donc on arrive trois mois après, et trois mois après on se dit « Qu'est-ce qu'on s'était dit ? C'est quoi ce truc ? » Et on refait la même réunion en essayant de se remémorer ce que t'as raconté, on dit peut-être pas les mêmes choses, on oublie, voilà. Et donc en fait, il y avait une perte de temps phénoménale, et en plus, tu peux pas partager la connaissance facilement. C'est-à-dire qu'en fait, si quelqu'un vient te poser une question sur un des sujets dont t'as déjà discuté, tu dois te rappeler ce qui s'est passé, voilà. Donc... Ensuite, il y a eu le... Donc ça veut dire que cette boîte, on n'était pas bien préparé, donc on a eu un moment où on a dit, allez, il faut faire de la documentation, et donc on a eu un gros effort de commencer à écrire des choses, mais c'était... Mais du coup, on avait quand même perdu tout un historique, qui était plus ou moins dans les têtes des gens.

Terry : Pour bien poser ce que tu viens de décrire, c'est exactement ce qu'on appelle le travail synchrone. Au-delà de l'aspect est-ce que tu le fais en étant là, c'est sur site, mais c'est cette idée de dire que moindre question, moindre sujet, hop, tu vas faire intervenir les personnes concernées et tu vas trouver ta réponse tout de suite sans poser la question de maintenant que j'ai la réponse, est-ce que je la capitalise quelque part ? C'est l'exemple même du travail synchrone.

Mathieu : Donc tu as des mauvais réflexes. Et nous, ce qui s'est passé en plus, c'est qu'à un moment, on a C'est pas qu'on a vendu la boîte, mais si tu veux, on avait notre solution SaaS et on l'a dupliquée pour un client, donc elle a été vendue à un client qui devait, donc l'équipe tech devait acquérir toute la connaissance et exploiter notre solution SaaS tout d'un coup. C'est le contraire du SaaS en fait, tu splits le SaaS en deux, nous on a exploité notre SaaS pour nos clients, on avait un client qui allait exploiter son propre SaaS sur ses propres serveurs, etc., qui allait tout opérer. Et donc effectivement, le passage de connaissances a été très difficile, parce que, ben, tout était dans la tête des gens. J'exagère un peu, mais c'est quand même ça l'idée. Alors que si on avait de la documentation des choses, on aurait dupliqué la documentation, on aurait dit regardez ça, faites-vous-même, etc. Et derrière, ils auraient pu prendre en main ce logiciel beaucoup plus facilement. Et donc, tout ça pour dire que cette expérience-là, moi, ça m'a traumatisé. Mais voilà, en tout cas, j'ai bien compris qu'à un moment... Donc je suis devenu un petit peu l'inverse. Pour un moment, je me suis dit, il faut tout documenter. Je me rappelle j'ai eu des entretiens il y a deux ans et demi où il y a des gens je leur ai fait peur en leur disant il faut tout documenter mais il est fou il veut tout documenter mais voilà le message derrière c'était ça c'était c'était il faut au maximum écrire ce qu'on se dit, écrire les décisions qu'on prend et le raisonnement derrière aussi c'est ça qui est intéressant c'est à dire que des fois t'écris juste la décision que t'as pris mais t'as quand même la question de pourquoi t'as pris cette décision et si tu l'as pas écrit quelque part s'il n'y a pas la discussion qui a mené à ce raisonnement bah ça rouvre les points il y a des gens qui vont avoir les mêmes peut-être objections à la décision que t'as déjà eue, et donc on va reposer la question, mais qu'est-ce qu'on avait dit déjà sur cette objection-là, etc. Donc, tout d'abord, en revenant au télétravail, le télétravail, indépendamment du côté « je suis à distance », il favorise le travail asynchrone, parce que c'est beaucoup plus difficile de taper sur l'épaule de son voisin. Et en fait, on va pas... Tu peux faire des Google Meet à chaque fois que t'as une question, etc., mais C'est moins pratique. Donc, tu vas utiliser des outils de communication écrite, comme déjà Slack, qui n'est pas forcément le meilleur outil pour documenter, mais au moins, il te permet déjà d'avoir des traces. Donc nous, même ça arrive aujourd'hui chez ACASI, qu'il y ait des discussions qui soient faites sur Slack. Alors Slack ne fait pas office de documentation, mais nous on a Notion pour tout ce qui est documentation, qui est notre workspace global en fait, pas que pour la documentation, c'est vraiment même notre... C'est ce qu'on appelle notre operating system de boîte, donc un outil ultra puissant. Mais quand on a une discussion sur Slack, on ne va pas forcément tout recopier dans Notion, mais on va au moins créer une page Notion avec le contexte, peut-être la décision, et on va lier la discussion Slack. On a toutes ces traces-là et en fait on gagne un temps fou. Moi je l'ai noté un nombre de fois incalculable, vraiment même deux semaines après des fois je me rappelle plus pourquoi on a parlé d'un sujet. Tu parles tellement de sujets dans deux semaines que tu te souviens plus. Là on a eu un exemple très récemment où en fait on a fait un changement. Donc je vais remettre un peu le contexte. Aujourd'hui, nous on a un système qui permet via Notion aux équipes de faire des demandes sur le produit. Donc de dire voilà, il faudrait changer ça, adapter ça. Donc là on avait une demande sur un document légal où on devait rajouter une mention. On l'a fait il y a cinq mois. Si on avait été en travail synchrone, la personne nous l'aurait dit, côté produit, on aurait peut-être fait un ticket Jira. On faisait quand même des tickets Jira, donc ça permet quand même de retrouver. Mais disons, imaginons qu'on n'a pas le ticket Jira, juste quelqu'un nous l'a dit. Enfin si même, on fait un ticket Jira, On développe le truc, on le met en prod, et puis cinq mois après on s'est aperçu qu'en fait on n'aurait pas dû faire ça. On s'est aperçu que du coup cette formule qu'on avait achetée dans le document légal, ça nous créait plus de problèmes que ça en résolvait. Et donc la question est venue légitimement pourquoi on a fait ça. S'il n'y avait que le ticket JIRA, bon peut-être j'aurais pu écrire dedans On a pu tracer la demande, qui l'avait fait, avec pourquoi elle avait eu des problèmes à l'époque. On est revenu en arrière, mais on sait ce qu'on a fait et pourquoi. tout ça te fait gagner du temps parce que ça évite de spammer la moitié de la boîte en disant pourquoi on l'avait fait, essayer de retrouver, personne s'en rappelle, etc. Et donc voilà, donc le télétravail, moi je trouve que ça favorise ça. Clairement, en tout cas, je le vois. Après, voilà, de nouveau, tu peux faire du télétravail sans bien faire du travail asynchrone. Mais voilà, donc du coup, nous on essaye aussi, même des fois, si tu fais juste une discussion slack, un peu synchrone, un peu pas bien, ou même quand on a une discussion, par exemple, après le daily, On peut avoir une discussion, mais si on prend une décision, on essaie de l'écrire quelque part. En fait, on essaie d'avoir cette discipline et ça devient un réflexe après pour chacun. Et voilà. Donc c'est un petit peu tous les bénéfices que je vois au travail asynchrone. Après du coup, effectivement, ce que tu disais, c'est pas... Le télétravail, c'est pas juste ça. Le télétravail te pousse à ça. Si on peut rentrer dans le sujet du télétravail ensuite.

Terry : Avant d'aller dans le sujet du télétravail à proprement parler, je voudrais rebondir sur ce que tu dis qui est hyper pertinent. C'est communément acquis de se dire quand tu fais une erreur, il n'y a pas de problème que tu fasses une erreur, mais ne la fais pas deux fois la même. c'est beaucoup moins acquis, encore une fois, le fait que quand tu prends une décision et que t'as réfléchi, t'as débattu sur la prise de décision, ben il faut pas que tu te reposes deux fois la même question sur pourquoi on a pris cette décision. Et là ce que tu viens d'expliquer c'est exactement ça, c'est-à-dire que ce qui est le plus important et d'où l'intérêt du travail synchrone, au-delà du télétravail, c'est le processus qui a mené à la décision. Même si ce processus tu veux le remettre en cause 6 mois, 5 ans, 2 ans après, au moins tu perds pas tout ce temps qui a été passé de réflexion en fait, et même si ce qui a été réfléchi à l'époque a changé avec les paramètres d'aujourd'hui, tu vas pouvoir recapitaliser là-dessus, donc c'est un point vraiment, enfin t'as insisté là-dessus et je pense que c'est un des points clés de l'intérêt pour moi du travail asynchrone, de la même manière qu'on dit on peut pas répéter deux fois la même erreur sinon que c'est que t'as pas appris. J'ai envie de dire on peut pas se poser deux fois la même question et débattre deux fois de la même chose sinon c'est qu'effectivement on a beaucoup de temps à perdre quoi. Donc la suite totalement alignée.

Mathieu : D'ailleurs je rebondis là, ce sujet là en fait il est très bien traité par Alan, tu vois l'assurance maladie, la Mutuelle, enfin je sais plus trop ce qu'il faut dire mais eux ils ont fait des super articles là dessus, ils disaient, alors ils le vendent un peu en disant nous on a arrêté les réunions, Ce qui n'est pas forcément vrai, mais en tout cas ils ont arrêté les réunions de prise de décision, c'est-à-dire que toutes les prises de décision se font de manière asynchrone. Ils utilisent GitHub Discussion qui est finalement l'équivalent d'un forum, donc nous on utilise ça aussi quand on a des discussions. Alors on ne l'utilise que dans l'équipe technique aujourd'hui, ce n'est pas généralisé dans l'ensemble de la boîte, mais peut-être ça viendra. Et on fait ça. Effectivement, t'as un sujet, tu décris des pratiques, des choses que t'es en train de mettre en place, et derrière, les gens peuvent les challenger, poser des questions si c'est pas clair, etc. Et effectivement, du coup là, c'est hyper utile parce que tu as toute la discussion et quand quelqu'un de nouveau arrive, en plus on oublie ça, c'est quand quelqu'un de nouveau arrive, c'est sûr qu'il va y avoir des questions. Et toutes ces questions-là, il a la réponse, il a le raisonnement, il peut suivre un petit peu ce qui s'est passé. Effectivement, comme tu dis, il y a de nouveaux éléments. Donc voilà, si jamais un truc intéressant à lire, c'est les articles d'Alan sur « On fait pas de meeting ». Ils sont top, vraiment, moi je me suis inspiré de ça ici et ça marche vraiment bien.

Terry : Super, merci pour la reco, effectivement ils font partie de ces belles boîtes qui ont mis en place ce type de culture. Il y a aussi, j'en profite pour donner ce que peut proposer 360 Learning sur leur... ils ont carrément créé une sorte de... alors j'ai pas envie de mal paraphraser ce que m'avait dit Audrey à l'époque mais quelque chose qui s'appelle convexity qui est en fait une façon de culture d'entreprise qui est totalement liée à la synchrone et donc ils ont plein plein de mécanismes qu'ils expliquent dans un doc aussi PDF là dessus. Toujours pour rester un petit peu sur le travail asynchrone, sur ce que tu viens de dire sur les réunions et sur l'aspect tech, c'est-à-dire qu'Allan c'est aussi une boîte très tech, c'est un peu comme avec une culture fort tech, donc les gens qui sont moins tech qui nous écoutent, ils pourraient se dire ouais ça marche bien pour les devs, ils mettent leur doc sur leurs outils, ils ont l'habitude de fonctionner comme ça. je pense que c'est important de vraiment montrer l'intérêt, donc on utilise souvent la métaphore de pas de réunion, même si en réalité c'est pas tout à fait ça, c'est beaucoup plus nuancé, par contre pour ce point des réunions, un des problèmes qu'on a avec les réunions souvent, dans les organisations plus traditionnelles, c'est le fait que si t'es pas dans la réunion, eh ben t'es lésé d'une manière ou d'une autre. Et que du coup c'est pour ça que parfois tu te retrouves dans des réunions où t'as 10 personnes dans la réunion, si tu calcules le coût de la réunion avec le nombre de personnes qu'il y a dedans et la durée que ça a, ça devient un frein marimineux. Et donc tu te retrouves des fois avec des gens et ils disent « ah bah tu m'as pas invité à la réunion ». Et parce qu'effectivement dans l'organisation, s'ils y sont pas, il manque d'informations, donc manque de contexte, donc voilà, et donc il y a des inégalités qui se créent. Et ça, peu importe que tu sois sur du produit tech ou pas tech, le fait de documenter, si t'es pas à la réunion, si t'as envie de t'informer sur le sujet, tu vas pouvoir aller lire des comptes-rendus bien structurés, tu vas pouvoir aller lire la réflexion et du coup avoir autant d'informations que si t'avais été dans la réunion. Et là-dessus, je pense qu'il y a vraiment un point aussi d'évangélisation, de passer cette culture-là dans des boîtes même moins tech. de se dire, de poser par écrit, ça permet aussi de pousser à, en tout cas moi c'est ma conviction, à l'horizontalité, quelque chose qu'on essaye de, enfin qu'on voit qui devient de plus en plus courant, c'est-à-dire d'avoir des organisations où la décision est beaucoup plus collégiale, ça a vraiment cet intérêt-là.

Mathieu : Mais du coup, pour reparler de ce sujet-là avec Alain, effectivement, GitHub Discussion, ça fait un peu peur parce que GitHub, c'est associé à la tech. C'est rien d'autre qu'un forum, en fait, où tu peux parler, répondre, etc. C'est rien d'autre que ça. Donc, on pourrait parler d'autres outils. Et eux, ils l'utilisent effectivement, exactement comme tu dis, en transversalité, c'est-à-dire que tout le monde a accès à toutes les conversations. Alors se pose la question de comment tu vois les choses pertinentes, donc j'imagine qu'ils ont, là je connais pas bien les détails mais ils ont un système de tag, des choses comme ça pour que tu vois ce qui est pertinent pour toi. Mais tu peux participer à tout, c'est-à-dire que tu es un dev, s'il y a une discussion sur un truc marketing, Alors après, à toi de peut-être pas mettre ton grain de sable partout, j'imagine qu'il faut faire un peu attention à ce que tu fais, mais si tu as un avis qui peut être pertinent ou un angle que les autres n'ont pas vu, tu peux y participer. Donc, ça permet effectivement de ne pas être... Donc voilà, dans une organisation traditionnelle, ça n'a aucun sens que des devs viennent à une réunion marketing, alors peut-être tu pourras en prendre un de temps en temps pour dire j'ai un point de vue externe, etc. Mais là, du coup, tu scales ce système-là. Donc c'est ça que moi je trouve hyper intéressant. Et ça suppose effectivement que les gens soient quand même disciplinés parce que c'est facile de se perdre dans 50 000 discussions et de vouloir participer à tout.

Terry : Après sur la notion de participation, ce que j'ai envie de dire c'est que ça me fait penser aussi à l'autre intérêt, c'est l'intérêt de l'alignement, c'est-à-dire que même si t'as aucune légitimité à venir donner ton avis sur ce sujet dans lequel il y a une expertise déjà dédiée dans la boîte, par contre si toi tu comprends pas pourquoi on te demande de faire quelque chose, tu peux très bien aller lire ces comptes rendus là pour comprendre les réflexions et là du coup te dire ah oui je comprends et donc tu te réalignes en fait avec l'objectif de la boîte et tu te retrouves pas en train de faire un truc où tu dis franchement ça me fait chier de faire ça je comprends pas pourquoi je le fais parce qu'on me l'a dit voilà. Donc là-dessus, je pense qu'il y a aussi ce fort intérêt pour aller vers le télétravail.

Mathieu : Sur le travail asynchrone, un truc qu'on n'a pas abordé, c'est aussi les interruptions. L'asynchrone te permet de t'organiser. Et ça, c'est fou parce qu'aujourd'hui, quand on te tape sur l'épaule toutes les deux secondes alors que tu es en train de faire un truc, tu finis ta journée en ayant été interrompu toute la journée. Et ça c'est prouvé, que grosso modo quand tu es interrompu, si t'es sur une tâche un petit peu compliquée, tu mets 20 minutes à te remettre dedans, donc en gros si t'es interrompu 8 fois dans une journée, t'as perdu 2h30. Concrètement, vraiment de juste te reconcentrer. Et donc moi sur la tech j'aime bien l'illustrer sur le fait qu'en fait à chaque fois que t'interromps un tech, tu crées un bug concrètement, parce qu'il perd sa concentration, il perd... Quand tu développes, alors il y a plein de techniques pour minimiser ça, mais tu as quand même du contexte dans ta tête, et quand on t'interrompt avec une question ou autre, tu perds ce contexte. Et reconstruire ce contexte, difficile de le reconstruire à l'identique, fatigant, et à la fin t'as oublié des trucs. Et donc voilà, j'aime bien dire ça. Il y a des très bons devs qui me contrediront en disant si tu fais du TDD ça n'arrive pas, ce qui est plutôt vrai. Mais voilà, la réalité c'est que tout le monde n'en fait pas, que t'es pas toujours en train de faire du TDD.

Terry : Et j'adore cette métaphore, c'est vrai que quand tu dis t'as du contexte dans ta tête, faut vraiment se dire, pour ceux qui sont pas devs, c'est effectivement quand tu devs, tu te retrouves avec... Ouais, t'as... Si tu fais du jeu vidéo, par exemple, t'as un état du jeu complètement figé dans ta tête à ce moment-là, et si on te coupe, là, ça explose tout, quoi. C'est comme si tu craches ton jeu, et effectivement, avant de te remettre là-dedans, je l'avais jamais entendu dit comme ça, et effectivement, la majeure partie des cas... Alors après, c'est vrai que le TDD, moi, à titre perso, je l'avais jamais expérimenté de manière stricte, donc je peux pas dire que quand tu fais du TDD, t'as pas le contexte, mais quand même, t'es obligé de te mettre dans un mode...

Mathieu : Si tu rentres là-dessus deux secondes, peut-être, pour pas perdre tout le monde... Le TDD, en fait, c'est... c'est une technique qui justement te permet de, bon, de designer du code, mais c'est pas ça qui nous intéresse là, mais de minimiser le contexte. C'est-à-dire qu'en fait, tu as une procédure pour développer, c'est-à-dire t'écris un petit test, et ensuite t'écris le code minimal qui permet que ce test fonctionne, passe en fait. Et donc du coup, c'est une procédure itérative qui fait que t'es toujours en train de faire des tout petits pas. Donc si on t'interrompt, soit t'étais en train d'écrire le test, et donc il faut te rappeler le test que t'étais en train d'écrire, mais il est petit, donc ça va, c'est facile, soit t'étais en train d'écrire le code qui devait satisfaire ce test. Et du coup, normalement, tu reviens, t'as ton texte qui marche plus, bon ok, tu prends 3 minutes à te dire « Attends, comment je fais marcher ce texte ? » mais t'avais pas beaucoup de contexte dans la tête, donc... Voilà, ce processus itératif qui fait que tu fais des tout petits pas minimise un peu le contexte. Alors c'est pas tout à fait vrai, c'est-à-dire que des fois il faut quand même te rappeler c'est quoi la problématique sur laquelle je suis en train de travailler, où je veux aller, etc. Donc c'est pour ça que l'histoire de contexte elle n'est pas liée que à l'activité de développement. Tout le monde a du contexte dans sa tête dès qu'il fait une activité où il se concentre. Tu fais une présentation, t'as du contexte où tu veux aller, si quelqu'un arrive tu dis attends c'était quoi l'étape que je voulais faire après, bref ce contexte il est là. Mais c'est juste pour rentrer deux secondes sur le TDD, c'est pour ça que le TDD te permet un petit peu de minimiser ce truc-là.

Terry : Yes, et ça me fait penser, encore une fois avant de switcher plus sur la partie télétravail, du coup pour donner un peu plus aussi un avis et une opinion et les problématiques que peuvent rencontrer des boîtes qui veulent passer sur une organisation plus asynchrone, c'est-à-dire que là on prêche un peu le pour. Donc moi je vais me faire l'avocat du diable, je vais te dire ok, génial, culture de l'écrit, je capitalise aussi sur mes collaborateurs, si jamais ils partent, je ne me retrouve pas avec un trou complet béant pendant 2-3 ans, le temps que les autres récupèrent la compétence, super. Par contre moi j'ai des collaborateurs qui ont vachement de mal à poser ce qu'ils ont dans la tête par écrit, que tout le monde le comprenne. J'ai aussi une culture d'entreprise qui est fortement axée sur cet échange par la voix en direct. sur cet aspect, comme tu le disais aussi, où les gens prennent un café et débloquent des situations à ce niveau-là. Et du coup, encore une fois, en me mettant dans la peau sur une boîte comme ça et en me faisant un peu l'avocat du diable, je pourrais te dire, pour moi, cette logique asynchrone, c'est soit tout ou rien, c'est soit je suis une entreprise qui, depuis le début, ou en tout cas qui décide de faire un basculement complet de sa culture vers une culture totalement asynchrone, où on reste dans un mode où les gens s'adaptent, mais je peux pas imposer à moitié de la synchrone et du synchrone pour le reste. Toi, quel serait un peu...

Mathieu : Alors, t'as plusieurs points. T'as effectivement le point les gens qui sont moins à l'aise. Donc ça, effectivement, t'en rencontres tout le temps. Tout le monde est plutôt moins à l'aise à l'écrit. Et puis t'as l'impression de perdre du temps. Tu te dis... Écrire par rapport à juste dire à la personne, c'est plus facile, voilà. Donc c'est plus facile de dire. Donc je pense que c'est une habitude à prendre. Nous on a ce cas-là, on a des gens qui sont moins à l'aise à l'écrit. Mais pour moi ce qu'il faut avoir c'est un effort à faire. Si t'es pas à l'aise avec ça, faut t'entraîner, ça se travaille, apprendre à écrire, passer du temps là-dessus. Et je pense quand même qu'il faut de la synchrone par défaut. Il faut que ton réflexe soit la synchrone. Tu le vois très bien, enfin j'exagère, mais tu le vois assez bien quand tu ne te comprends pas. C'est-à-dire que tu écris, et tu sens, j'ai le cas en ce moment exactement, on s'est dit, tu vois hier on avait une discussion sur un bout de code, et en fait on a fait 3, 4, voilà, et à chaque fois on a l'impression qu'on a compris, et en fait quand on voit la réponse suivante on se dit non en fait on ne s'est pas compris. Et donc là on s'est dit, ok, ce matin au DSM, donc au Daily, on s'est dit, bon, on s'est pas compris, on n'y arrive pas par écrit, faut qu'on fasse un point, 10 minutes aujourd'hui, on va se parler, et ça sera très clair. Et c'est comme ça. Et en fait, ça, ça te permet de dire, voilà, part des fois synchrone, et dès que ça marche pas, repassons sur le synchrone, on sait qu'effectivement, se parler c'est plus direct. Donc moi je trouve ce mode de fonctionnement pas mal, ça suppose d'être capable de dire que tu comprends pas, qui est aussi un sujet de culture d'entreprise. Est-ce que les gens sont à l'aise avec le fait de dire qu'ils ne comprennent pas ? A savoir que des fois, ce n'est pas eux qui ne comprennent pas, c'est toi qui expliques mal. Donc voilà. Mais si tu arrives, je trouve, à diffuser ce truc-là, ça marche plutôt bien. En tout cas, moi, ce que je vois aujourd'hui, c'est les gens, qu'ils soient seniors, juniors ou quoi, quand ils ne comprennent pas, ils savent le dire. Et tout le monde est OK pour prendre du temps pour expliquer ou pour être sûr que tout le monde a bien compris la décision, ce qu'on est en train de faire, etc. Donc voilà. Moi, je l'aborderai comme ça. En tout cas, c'est comme ça qu'on le fait aujourd'hui.

Terry : Yes, là-dessus, je partage ta vision. En gros, je préfère une organisation qui est par défaut asynchrone. Malheureusement, on ne va pas pouvoir donner de conseils. On n'est pas des experts de la transition vers les boîtes de synchrone vers l'asynchrone. Mais je pense que pour les boîtes qui sont synchrones, qui se posent ces questions-là, ça peut déjà valoir la peine de lire des articles type ce que peut faire Alan, une boîte qui est hyper connue qui est GitLab, qui a quand même un mode de fonctionnement aussi asynchrone dans la même idée. 360 learning, donc il y a quand même des boîtes qui ont, et on parle là de boîtes qui ont plusieurs centaines voire milliers pour GitLab de salariés, donc c'est pas des petites organisations. Et donc peut-être que les personnes qui sont dans des structures beaucoup plus avec une culture synchrone peuvent s'inspirer un peu et voir comment appliquer ça. Mais c'est vrai que j'imagine aussi que donc, enfin, je comprends que ça soit pas facile quand ton organisation elle est là depuis 20 ans et qu'elle a une culture du synchrone. Surtout quand tu veux basculer vers un mode complètement très commun.

Mathieu : Quand tu fais du synchrone, nous on a des réunions synchrones où on a envie d'avoir une trace. Donc à chaque fois qu'on a une réunion synchrone, on a envie d'avoir une trace. Il y a une des personnes dans la réunion qui est la personne qui prend les notes, qui est en charge du compte rendu, et donc ça te donne une trace de cette réunion synchrone. Je pense quand même qu'il faut faire de la synchrone. Je pense que la synchrone a d'autres propriétés. La synchrone permet notamment... Le problème de la réunion synchrone, c'est que t'as toujours celui qui parle le plus fort, celui qui monopolise, celui qui est le chef aussi, tu vois, qui a une... je vais pas dire une aura, mais en fait, il a une autorité qui fait que les autres, des fois, osent pas trop se mettre en porte-à-faux, c'est un peu inconscient, mais même avec, je pense que même avec une bonne culture où tu peux challenger le chef, entre guillemets, C'est pas toujours facile. Et donc, si tu fais de la synchrone, tout le monde peut s'exprimer, prendre le temps de structurer sa pensée, etc. Donc voilà, je sais plus pourquoi j'ai dérivé là-dessus, mais je trouvais ce point-là intéressant aussi. Donc, pour moi, il faut rester sur la synchrone. Mais si tu fais du synchrone, au moins, fais des comptes rendus, essaye de traquer ce qui s'est dit. Il y a des outils de... Il y a des trucs assez fous qui sont en train d'arriver sur... Tu peux enregistrer toute la réunion et demander à des outils basés sur du traitement de langage de faire un résumé, le structurer, etc. Donc aujourd'hui, en plus, on est en train de voir arriver des choses qui vont nous permettre de faire du synchrone sans cette... ce fardeau de la prise de notes et d'écriture, et qui vont nous résumer ça de manière hyper structurée et hyper propre. Donc voilà, je pense qu'il y a quand même des solutions, l'insynchrone restera quand même toujours utile pour les problématiques que je racontais.

Terry : Ça me fait penser aussi à deux points, le premier sur les réunions et tu parlais donc souvent ce qui peut se passer dans les réunions, on l'a tous vécu, c'est qu'il y a une personne qui a plus on va dire de capacité à prendre la parole et d'autres qui ont plein d'idées hyper pertinentes mais qui osent pas parce que c'est pas dans leur tempérament. et c'est vrai que du coup ça me fait faire un lien avec aussi des sujets qui je pense sont d'actualité, enfin c'est pas ce que je pense, ce sont d'actualité des sujets aussi de la représentation féminine dans les métiers tech et pour avoir échangé du coup aussi avec d'autres personnes à ce sujet c'est qu'il y a des femmes qui me disaient bah moi dans une culture asynchrone l'intérêt que j'y vois aussi et que j'ai vraiment vécu c'est le fait que je me sentais beaucoup plus valorisé en termes de compétences c'est à dire puisque j'avais pas cette Déjà ce frein indirect que je devrais pas avoir mais que j'avais quand même à prendre la parole ou à donner mes idées, là dans une culture asynchrone en fait il n'y a pas de notion de genre puisque c'est juste ce qu'il y a vraiment en termes d'idées et donc ça remet plus à plat aussi les choses et on se concentre sur le cœur en fait qui est ce que tu as réussi à produire en termes d'idées.

Mathieu : Ça réduit un peu les biais qu'on a. Ouais je suis d'accord.

Terry : Et le deuxième point, je crois que c'était avec toi qu'on en avait parlé mais tu me diras si ce n'est pas le cas, c'était sur le sujet des réunions du coup, je crois que c'était Amazon qui avait une technique particulière justement parce qu'un autre problème qu'on a dans les réunions classiques, c'est quelqu'un qui arrive dans la réunion et qui n'a même pas lu le brief. et qui sait pas de quoi on va parler, donc tu perds encore un quart d'heure à répéter à tout le monde le sujet de la réunion. Et du coup, c'est avec toi qu'on...

Mathieu : Non, je crois pas, mais je vois très bien de quoi tu parles. Ou alors, j'ai écouté l'épisode, mais oui, je vois de quoi tu parles.

Terry : Alors, le sujet, c'était de se dire que... Donc, c'était Amazon, il me semble, qui demandait, en fait, clairement à ses collaborateurs qui allaient en réunion de lire le brief au moment du début de la réunion.

Mathieu : C'est des silent meetings, un truc comme ça, non ?

Terry : Alors c'était le fait qu'en fait personne n'avait le brief à part quand ils arrivent et en fait comme ça tout le monde lit pendant dix minutes le brief et tout le monde est clair sur quel va être le sujet de la réunion et il n'y a pas de problématique de faut le répéter ou je ne l'ai pas lu etc et au moins tout le monde a le même contexte.

Mathieu : C'est un bon sujet parce qu'effectivement on parlait de faire un compte rendu mais aussi quand tu fais une réunion t'imposer le fait d'écrire un ordre du jour, de lister les problèmes qu'on veut résoudre, ceux dont on va parler, et effectivement tu as le sujet de dire ok j'ai fait ce travail c'est bien mais effectivement 90% du temps tu vas dire aux gens lisez-le avant mais personne ne lira avant donc t'es obligé de prendre une partie de la réunion au début pour le faire. Donc ça je pense effectivement Amazon j'ai entendu d'autres boîtes faire ce truc là mais c'est eux qui l'ont popularisé mais c'est vrai que c'est un moi je trouve ça important je trouve ça vraiment sinon en fait ce qui se passe c'est que t'as une personne qui le redit t'as ça aussi t'as une personne qui va redire l'ordre du jour mais le dire, c'est pas pareil que toi le lire et t'en imprégner, poser tes questions. Et d'ailleurs je crois que même ce qu'ils font, c'est que des fois ils font des réunions synchrones, où en fait tu lis, et tu poses tes questions par écrit directement sur le document. En fait c'était vraiment un silent meeting en fait, où... Donc là ça force, c'est un espèce de truc synchrone, mais où tu vois un petit peu tout le monde s'exprimer, et du coup tu réduis aussi le problème dont on parlait tout à l'heure, qui est ceux qui prennent la parole le plus fort, ceux.

Terry : Qui monopolisent, etc. hyper intéressant. Donc maintenant, après trois, quatre tentatives de switcher vers la télé plus télétravail, on switch vers le télétravail. Donc quel est déjà un peu toi, ta vision là-dessus et par rapport à ce qu'on vient de dire aussi sur la synchrone ?

Mathieu : Donc le télétravail, ce que je disais, c'est qu'effectivement ça encourage la synchrone. Parce que du télétravail sans la synchrone, c'est compliqué concrètement. Ça veut dire que tu dois toujours faire des meetings, etc. En fait, de base déjà, tu peux plus taper sur l'épaule des gens, donc t'es obligé d'avoir un outil de communication qui a ses inconvénients, comme Slack ou n'importe quel outil de chat. Donc ça, c'est le premier truc que je trouve intéressant, ça te pousse à bouger vers ça. Au-delà de ça, après moi, le télétravail, je trouve que c'est simplement un outil de liberté incroyable, c'est-à-dire que tu Gagne du temps, de pas faire de trajet le matin, donc c'est aussi des moments pas forcément très agréables quand t'es à Paris, les trajets dans le métro c'est jamais... enfin je sais pas s'il y a beaucoup de gens qui aiment ça peut-être, mais je pense que c'est pas la majorité. Donc tu gagnes tout ça. Tu gagnes en flexibilité, c'est-à-dire qu'en fait ça te permet aussi de... travailler au moment que tu veux. Ça va avec la synchrone aussi, parce qu'à partir du moment où tu as la synchrone et le télétravail, tu t'organises un peu comme tu veux. ont des rythmes différents. Le télétravail permet aux entreprises de s'adapter à leurs employés. au lieu de dire que c'est 9h-17h tous les jours, il faut venir à cette heure-là, il faut être réveillé, voilà. Et donc moi je trouve ça fantastique. Après c'est un titre perso, moi j'habite à Bordeaux maintenant, donc ça c'est bien aussi, c'est-à-dire que ça m'a permis d'avoir un confort de vie que j'avais pas ici, en tout cas qui était plus compliqué à avoir.

Terry : Donc voilà, c'est... Et du coup, un point quand même sur ce que tu viens de dire par rapport à ça, c'est-à-dire que, par exemple, le fait que je mange à 14h, moi je bosse plus du soir versus le matin, dans une logique télétravail sans penser au travail asynchrone, ça marche pas. C'est-à-dire que dans une logique travail asynchrone, effectivement, on n'a pas besoin de toi à 14h parce que, de toute façon, les sujets pour lesquels on a besoin de toi, ils sont posés par écrit. Et si tu bosses plus le soir que le matin, pareil, on n'a pas spécialement besoin de toi parce qu'on travaille de manière asynchrone. et en fait c'est aussi ça je pense un des gros sujets qu'il y a autour du télétravail pour des organisations plus traditionnelles qui ont du mal en fait à être sur des options des fois full remote ou vraiment de l'hybride mais l'hybride très très flexible on va dire et qui t'impose en fait des plages horaires et qui t'impose des jours de présence c'est parce que en réalité elles ont du mal à désynchroniser le travail. Et donc en fait, oui tu travailles de chez toi, mais en fait tu dois faire de 9h à midi, de 14h à 17h, et t'es obligé d'être présent sur ces plages horaires-là, limite tu peux avoir des pings, je sais pas moi, sur du Slack, du Google Chat ou autre. Enfin, parce qu'en réalité, ils n'ont pas cette culture de la synchrone. Et en fait, le télétravail sans la synchrone, c'est presque, je dirais, ça pourrait être presque pire que le travail synchrone sur site, parce que tu te retrouves chez toi avec les contraintes du synchrone.

Mathieu : — Mais t'as plus le temps en fait. — Voilà. — Ouais, je suis d'accord.

Terry : — Et je pense que c'est aussi pour ça qu'on voit revenir des gens qui disent « Ah mais moi le télétravail, ça va pas du tout ». parce que aussi il y a cette logique là où en réalité ils font du travail synchrone chez eux, ce qui est encore une fois je pense plus compliqué.

Mathieu : En fait, effectivement, quand tu dis télétravail, t'as tout et t'as rien dit. Télétravail, t'as juste dit, tu restes chez toi. Donc, pour l'entreprise, potentiellement, tu fais quoi ? Tu économises sur des bureaux. La personne, elle gagne sur les temps de trajet. Et puis, ça peut être tout, effectivement. Si c'est toujours synchrone, ça peut être tout. Et juste, tu vois pas les gens, donc tu perds le lien. Et donc, en fait, effectivement, c'est pas du bon télétravail. Je vais pas dire que c'est pour ça que certaines personnes n'aiment pas le télétravail parce que... Si tu fais du 100% télétravail, il y a quand même cette différence. Même si tu en as synchrone, il y a ce côté « je vois pas les gens ». Moi je sais que je viens moins souvent au bureau puisque je suis loin, je vois les gens en mythe, etc. Mais c'est vrai que tu perds du lien. Mais ça, c'est chacun à sa, entre guillemets, je veux dire, sa tolérance ou ses besoins là-dessus. C'est-à-dire que tu as des gens, ils ont besoin de se voir une fois par mois, ça leur suffit. Il y en a d'autres, en fait, c'est plutôt plusieurs fois par semaine. Et il y en a, en fait, ils ont besoin de voir les gens tous les jours. Pour d'autres raisons aussi. Tu peux avoir des contraintes en fonction d'où tu habites. En fait, je sais pas, t'as des enfants qui sont chez toi toute la journée, peut-être tu préfères venir au bureau parce que sinon tu peux pas te concentrer. Donc il y a plein de raisons qui font, voilà. Donc c'est pour ça que le télétravail en soi, c'est un outil qui permet de donner aux gens de la flexibilité. Et c'est ça, effectivement, ce que les gens recherchent. C'est ça, c'est la flexibilité plus que le télétravail. Le télétravail, c'est juste un moyen de donner de la flexibilité. Donc effectivement, quand il y a des grèves, je reste chez moi parce que ça va être l'enfer dans les transports, même si j'aime bien venir au bureau. J'ai pas d'autres exemples qui me viennent tout de suite, mais voilà, c'est vraiment ça le truc important. Et du coup, si effectivement tu fais du travail synchrone, tu perds une partie de ce truc-là. Et puis après, si tu fliques les gens aussi. C'est-à-dire qu'en fait, si ton but, c'est de dire... J'ai entendu des trucs comme ça, des boîtes où t'as des logiciels installés sur les ordis des gens qui sont à distance, pour vérifier qu'ils sont devant leur ordi, que la souris bouge assez souvent, combien de temps de travail par jour, voilà. Donc ça, c'est... Pour moi, c'est des gens qui n'ont pas compris le télétravail, qui en plus font pas confiance à leurs employés. C'est hyper destructeur, c'est encore un autre sujet. Télétravail, t'as tout dit et t'as rien dit, mais avant tout moi je dirais plutôt flexibilité.

Terry : Yes, et pour quand même rebondir sur l'aspect flexibilité, je dirais du coup que t'as deux niveaux de flexibilité, c'est-à-dire que t'as le niveau flexibilité que t'apportes le télétravail dans une orga qui n'a pas la culture asynchrone mais qui est quand même un intérêt, c'est-à-dire exactement ce que tu disais, il y a des grèves, des gros problèmes de transport donc on peut bosser de la maison, mais on n'a pas une culture asynchrone donc quand même, il va y avoir une contrainte du fait qu'il va falloir faire des réunions en zoom et on va après avoir les problèmes de zoom fatigues parce que les gens passent trop de temps sur la réunion ou bah en cas de pandémie voilà donc tu as ce côté là. C'est le niveau 1 et le niveau 2 qui est pour moi le niveau vraiment intéressant qui est le télétravail dans une organisation asynchrone où là du coup pour toujours rester sur l'aspect flexibilité c'est-à-dire que tu vas demander aux gens, enfin dire aux gens de faire qui pour eux est le mieux. Et c'est là où on a toute la puissance, c'est-à-dire que les gens sont intelligents, c'est-à-dire que s'ils savent déjà que pour leur équipe ils ont besoin de venir, ils vont venir parce qu'ils veulent travailler dans le collectif. Si en plus de ça, des moments où ils ont des besoins de flexibilité, ils vont pouvoir bénéficier du fait qu'il y ait du télétravail et de la synchrone sans impacter du coup le business. Et ce niveau 2 je pense qu'il est quand même compliqué à avoir si tu n'as pas cette culture asynchrone. Et pour rebondir aussi sur le flicage, moi ça me rappelle une anecdote d'une de mes managers qui m'avait raconté dans une grosse boîte qu'il y avait encore fin des années 2010 des managers qui passaient dans les bureaux à 19h pour voir qui était là et savoir qui ils allaient faire passer en promotion l'année suivante. Et ça, c'est exactement ce qu'on peut... Alors je pense qu'on le voit quand même de moins en moins, mais quand tu parles, ou j'avais entendu aussi d'autres amis qui me racontaient qu'il y avait des logiciels, comme tu dis, qui vérifiaient soit comment la souris bouge, soit qui comptaient le nombre de fois où le clavier était tapé, quoi. Donc ce qui est complètement contre-productif, évidemment. On est, je pense, clairement alignés là-dessus, mais... Et pour fermer ce sujet du coup du présentéisme et surtout de la culture du présentiel, il y a aussi je pense, j'avais lu une étude là-dessus d'un think-tank français, sur le fait que les pays latins, donc du sud de l'Europe, ont une culture plus compliquée à avoir, enfin ont plus de mal à adapter la culture de la synchrone, et l'une des raisons c'est qu'on est latins, c'est-à-dire qu'on aime bien voir les gens parler, le chef il aime bien voir tous ces petits soldats en face de lui, donc les fameux open space où tu as le bureau du directeur et puis les 40 collab en face, il peut se lever pour montrer, il sait qu'il est chef quoi. C'est vrai que quand tes 40 collab ils sont éclatés sur la planète et que tu es derrière ton pc chez toi dans ton bureau, tu le sais moins, enfin tu le vois moins. Et donc cette culture latine, et du coup aussi du parlé, et donc du synchrone, faisait, selon cette étude en tout cas, que c'était plus complexe, enfin c'était une des raisons que l'étude mettait en avant, pour laquelle les pays type la France, l'Italie, l'Espagne, avaient plus de mal à adapter ces cultures que la Suède, la Norvège ou des pays qui sont plus nordiques et qui ont du coup moins cette culture, on va dire, très latine quoi.

Mathieu : Mais du coup c'est aussi, enfin, — Ouais, après, je sais pas ce que ça dit sur nous, les latins, mais c'est... Mais pour moi, tu vois, tu as ce sujet de dire... Si j'ai besoin de mesurer les gens par leur présentiel ou par... Si j'ai besoin un petit peu de les mesurer par autre chose que ce qu'ils produisent, c'est qu'aussi, en fait, je sais pas trop quoi attendre d'eux, je sais pas trop mesurer leur output et je sais pas leur demander quoi faire. Bah donc du coup, il y a un côté vachement... pas très rassurant sur notre façon de manager.

Terry : J'espère que ça se corrige petit à petit. Je pense qu'on a fait un bon tour du coup sur cette partie travail asynchrone, télétravail et en fait l'un ne va pas sans l'autre je pense. Donc maintenant si on bascule sur la partie plus tech, pragmatisme, qu'est-ce que déjà qu'est-ce que ça veut dire le pragmatisme au sein du monde des techos ?

Mathieu : Alors ça c'est hyper dur comme question parce que... Alors le pragmatisme, donc là on va parler un petit peu de ce qui est... Comment expliquer ça ? Je vais dire qualité de code mais je sais pas si ça va parler à tout le monde mais en gros c'est l'idée de dire tu... Quand t'es tech, tu passes ton temps à résoudre des problèmes via du code, grosso modo. J'exagère, des fois les meilleurs tech réussissent à résoudre les problèmes sans faire de code, c'est chouette, mais voilà.

Terry : Pour ceux qui se diraient « ah, c'est pas pour moi », ceux qui écoutent là, qui se diraient forcément « arrête d'écouter », il y a, je pense, quelque chose qui vous parlera aussi, qu'on entend beaucoup, c'est le sujet de la dette technique. Et donc il y a des liens qui pourraient être faits avec ce dont on va parler, donc continuez à écouter.

Mathieu : Ne partez pas, ça va être super. Donc tu as ce sujet et du coup tu dis, il y a comme dans beaucoup de domaines, il y a 50 façons de résoudre les problèmes et donc il y a la façon, je vais dire rapide, c'est je résous le problème maintenant, tout de suite, le plus vite possible et il y a j'y passe 10 jours, je fais un truc qui sera prêt, qui va fonctionner pendant 25 ans, j'exagère, je fais exprès de pousser le truc. Mais voilà, et donc tu as ce que quand tu étais que tu vas appeler la façon quick and dirty et à l'autre extrême du spectre tu vas avoir la façon propre quoi. Et le pragmatisme c'est c'est trouver un petit peu où tu mets ton curseur là-dedans en fonction de pas juste la partie code mais en fonction de effectivement la partie technique et puis la partie produits, business, etc. Donc c'est ça un petit peu le pragmatisme. Et le problème c'est que quand on dit je suis pas... Personne va te dire, moi j'ai jamais rencontré quelqu'un qui me dit je suis pas pragmatique. Le problème c'est que tout le monde est pragmatique mais chacun met son curseur à un endroit différent. Donc ça c'est ce qui génère énormément de discussion dans les équipes techniques. c'est que t'as rarement une façon de prouver que ton pragmatisme est le bon. Donc on a beaucoup de débats. Si t'es tech, tu peux aussi être avocat souvent. Pendant un moment, moi j'ai été dans cette boîte avant où au début effectivement on faisait vite. On faisait vite bien et t'as ce côté start-up où en fait on faisait vite pas bien du tout. t'as ce côté startup où en fait l'enjeu c'est de livrer rapidement parce que t'as le couteau sous la gorge. Donc tu peux, tu veux que ça marche, sauf que assez vite tu vas t'apercevoir que deux semaines après ce que t'as fait ben en fait ça pose plein de problèmes et tu vas avoir cette courbe un petit peu de ce qu'on appelle la vélocité, donc c'est la rapidité de ton équipe technique. qui va au début, c'est une espèce de flèche vers le haut, enfin ça va hyper vite, et puis petit à petit ça descend, ça descend, ça descend, et à un moment t'atteins une espèce d'asymptote où en fait tu vas hyper lentement, t'arrives plus à rien faire, parce que t'as fait tellement de choix quick and dirty au début, que t'arrives, enfin tu mets très longtemps à développer des choses, et puis souvent il y a des bugs qui vont avec, etc. T'as l'autre extrême, qui est de te dire... Ok en fait au début oui je vais bien réfléchir à la problématique, je vais passer trois semaines, je vais mettre une architecture, une architecture c'est... je sais pas comment expliquer ça mais c'est une sorte de... je sais pas comment expliquer ça.

Terry : La métaphore la plus simple c'est dans... tu prends le métier du bâtiment, si tu construis une maison, soit tu réfléchis à tes fondations de manière hyper poussée pour te dire que sur ta maison si jamais demain tu devais non pas mettre un étage mais 25, ta maison tiendra toujours. Sauf que bon peut-être que ça va pas être le cas de mettre 25 étages dessus versus bon tu pars sur le principe que de toute façon il n'y aura qu'un étage et tu t'arrêtes là en termes de réflexion sur le.

Mathieu : Console etc. Ouais c'est ça. Donc quelque chose de plus on va dire flexible, modifiable en tout cas plus pérenne dans le temps. Mais du coup, tu peux passer plus ou moins de temps à faire ça. Et si la durée de vie de ta startup, si au bout d'un an en fait, elle se casse la figure, ça n'aura servi à rien. Et le problème, c'est que peut-être, c'est un peu ta faute si ta boîte s'est cassée la figure parce qu'en fait, tu as passé 6 mois à faire bien l'architecture, personne n'a vu aucune feature, personne n'a pu utiliser quoi que ce soit. Et donc, tu as fait perdre 6 mois à la boîte. C'est un sujet vraiment hyper difficile. Moi, tous les jours, en fait, je me pose des questions là-dessus. Chaque décision qu'on prend, c'est un arbitrage. Et c'est un arbitrage qui est très dur parce que l'output est vraiment difficile à mesurer. Si tu compares avec, on en avait parlé un peu la dernière fois en fait, les métriques des équipes tech performantes. Donc ça c'est des choses, il y a une étude associée, et puis voilà, tu sais qu'il faut te déployer régulièrement, il faut regarder combien de temps tu mets à résoudre un bug, etc. Donc ça c'est des choses qui sont mesurables, qui sont un peu prouvées, donc tu sais, tu peux regarder.

Terry : Déployer, du coup, ça veut dire régulièrement, dans le cas des SaaS, tu sors des nouvelles versions de ton application assez rapidement, ou tu corriges des bugs assez rapidement, dans le cas toujours de software as a service, puisque c'est un des gros avantages de ces boîtes-là.

Mathieu : Et donc du coup, sur ce domaine-là, tu as des métriques, tu as une étude, etc. Sur la partie qualité de code, en fait, déjà, la qualité de code, c'est difficile à mesurer. Donc on a des outils qui calculent des choses, de la complexité, machin. C'est quand même assez limité. C'est-à-dire que des fois, il y a des choses, tu regardes, t'as A, t'as B. Il va falloir argumenter ce qui est mieux que l'autre parce que les outils, ils vont te faire des calculs, mais ça ne veut pas dire grand-chose. Et donc du coup, dans ces cas-là, Donc, tu passes ton temps à avoir des discussions avec ton équipe, à prendre des décisions là-dessus que tu ne peux jamais mesurer. Et donc, c'est un domaine, je ne sais pas si on peut dire ça, mais c'est Même, j'allais comparer avec le domaine un petit peu artistique en fait, tu fais des choses et il y a des gens qui aiment et des gens qui aiment pas et tu sais pas trop pourquoi. Bah là c'est encore pire en fait parce que ta boîte peut-être va cartonner et en fait ton code était fait n'importe comment. Mais en fait, le business était tellement fort qu'il a réussi à tirer le truc. Et tu as fait un truc super bien avec les bons choix au bon moment. Peut-être qu'ils étaient 100% parfaits, tu as fait les bonnes décisions pragmatiques, etc. Mais pour une raison, ton marketing n'est pas bon ou ton business n'est pas là et ça ne va servir à rien. Donc voilà, c'est un sujet sur lequel je trouve que sur les dernières années, les gens ont un peu évolué. C'est-à-dire qu'en fait, il y a 3-4 ans, je voyais beaucoup de gens arriver, notamment sur LinkedIn, parler beaucoup de qualité de code, à fond, dire il faut faire tout propre et tout, moi ce qui m'a... Enfin, même si je comprends le truc et je vois, mais c'était un peu trop binaire en fait. C'est-à-dire que non, des fois, en fait, il faut être OK pour dire là, je crée de la dette technique. J'accepte en fait ce qu'on appelle de la dette technique tactique. tu dis bah non en fait là je sais que ça va être moins bien que ce qu'on devrait faire mais en fait je sais que ce bout de code on va pas le regarder pendant trois mois cette feature elle va pas évoluer elle est terminée et donc tu la donc tu la touche pas donc voilà donc c'est un un vaste débat sur lequel j'ai pas trop de solutions et du coup aujourd'hui là sur LinkedIn je trouve qu'il y a plein de gens qui sont un peu revenus de ça et qui commencent à dire donc c'est bien d'apprendre à faire bien mais il faut savoir s'arrêter en fait il faut trouver toujours la limite de je passe des heures et des heures à faire la feature entre guillemets aux petits oignons mais personne va se rendre compte ou en fait elle va être aussi bien les gens vont l'utiliser, je sais qu'elle est un peu bancale, je sais peut-être qu'il y a 5% des cas où en fait ça crée des bugs ou ça marche pas, et c'est un peu ce que tu... Je sais pas si le lien est bon, mais en fait, quand tu fais un prototype, c'est un peu ça que tu fais. En fait, le prototype, tu vois, on a beaucoup cette discussion chez VTex, en fait, tu fais un prototype, donc tu le fais le plus vite possible, un peu crade, etc. Et il y a des gens qui vont dire, moi, même le prototype, en fait, je vais le faire hyper bien, dans les règles de l'art, etc. La réalité c'est que souvent ce prototype, une fois que les gens l'aiment bien, tu passes à autre chose et donc tu le retouches jamais.

Terry : Quand je dis pas cette chose, c'est surtout que souvent, ce que les techs craignent en général, c'est que le proto qui était au départ un POC, un proof of concept, devient un MVP, voire un produit industrialisé, sans avoir eu la nouvelle couche d'archi qui va bien, et du coup faut taper une maintenance derrière de quelque chose qui a été fait très vite. C'est aussi pour ça que les techs parfois peuvent dire là ton proto si tu m'assures pas que je vais après avoir du temps une fois qu'on aura validé le truc pour le retravailler, ça va pas se faire en une semaine mais ça va plutôt se faire en un mois quoi.

Mathieu : Mais du coup ce qui est difficile aussi c'est que quand tu es tech en fait tu as le côté le côté, ça dépend des techs, de nouveau, vraiment, je pense que t'as tout type de profil, mais tu en as qui vont être perturbés parce que le truc est pas bien. Et en fait, c'est pas grave, c'est-à-dire que peut-être que tout le monde s'en fiche, ça n'a aucun impact sur le produit, mais t'as des gens qui vont pousser pour résoudre cette dette parce qu'elle est là, juste parce qu'elle est là. Et ça, tu vois, c'est un... C'est un mauvais... C'est un mauvais réflexe, en fait, c'est un truc qu'il faut essayer de se battre. Moi, ça m'arrive aussi, tu vois, je sais, y a des trucs qui me turlupinent dans le teint, ce truc. Je sais que c'est pourri, c'est pas bien fait, mais tu vois, il faut être capable de dire non mais on fera plus tard quand on aura un vrai problème. Tant que t'as pas un vrai problème, et ce qui est difficile évidemment, c'est que tu vas avoir des problèmes, et il y a des problèmes que tu vas corriger de nouveau avec des petits trucs. Tu vas prendre une heure, tu sais que ça va pas être génial et tu vas corriger. Et puis il y a un moment où tu dis ok, quand est-ce qu'on investit ? On a eu dix fois le petit problème, espacé de une semaine à chaque fois. si on avait bien fait au début, on n'aurait pas eu ces 10 petits problèmes. Donc à un moment, il faut te dire, ok, à quel moment j'investis ? Et ça, c'est une discussion qui se fait pour moi entre un tech lead et un product pour essayer de trouver ce bon moment. Mais nous, côté tech, des fois, on a du mal à vivre avec la technique. Pas forcément parce que... Et pas toujours parce que ça pose des vrais problèmes côté produit. Des fois, ça pose des problèmes, tu vois. Tu sais que tu prends... Quand tu prends deux heures au lieu d'une heure, Est-ce que c'est grave, en fait, finalement ? Ça se discute à chaque fois. C'est bon, t'as perdu une heure, mais qu'est-ce que t'as gagné autre part ? Parce que si t'avais pris trois jours pour faire bien... C'est un sujet permanent où je vois pas de solution. dev, chaque tech a un avis différent sur la question, tu vas discuter avec des produits en face et chaque couple, je dirais, produit de l'idee va prendre des décisions différentes et je pense qu'on ne saura jamais qui a raison. On ne sait jamais en fait si on a pris vraiment la bonne décision. Donc c'est un truc dont moi je l'aime bien, mais je n'ai pas trouvé.

Terry : Le Ouais, la formule magique quoi.

Mathieu : Ouais, c'est ça.

Terry : Parce qu'il n'y a pas vraiment... Bon, pour te donner un peu moi mon regard là-dessus, mon avis, déjà pour remonter, ça m'a fait penser à plein de points, différentes choses que tu as dites là, mais sur le dernier point où tu dis souvent cette logique de, en tant que tech, de se dire ça je sais que c'est pas bien fait et je sais que ça va poser des problèmes plus tard, c'est aussi l'une des raisons pour laquelle c'est très difficile en tant que tech parfois de laisser quelque chose mauvais, c'est parce que si jamais le problème arrive, on va se dire ben oui, de toute façon je l'avais vu que ça allait arriver. et c'est toujours trouver cette limite du coup, enfin en tant qu'ingé en fait t'as cette logique d'anticiper les choses et du coup de vouloir bien faire pour que en fait t'aies essayé de penser un peu à tous les cas. Et quand tu sais que tu laisses volontairement des cas qui peuvent poser problème, quand le problème arrive ça fait toujours chier parce que tu dis bah oui je le savais. Et là-dessus, moi, l'avis que je pourrais avoir, ça serait de dire, en fait, tout est question de l'intentionnalité que tu mets dans la décision. C'est-à-dire de ne pas se positionner en mode, ah mais je n'ai pas le temps de bien faire les choses, mais plutôt de se dire, déjà, est-ce que je suis dans une boîte qui fait du business ou de la R&D ? Si je suis dans une boîte qui fait de la R&D, bon, ce n'est pas la même chose. Là, on va prendre le cas… L'horizon de temps n'est plus… Exactement, l'horizon de temps, le budget, enfin, c'est différent, mais on va prendre le cas. classique, on parle de start-up, scale-up, de boîtes qui cherchent à faire du business, donc la tech devrait être au service du business. Et donc dans cette logique là, pour moi ce qu'il faut c'est que lorsqu'il y aura des moments où il va falloir faire des choix techniques et du coup ce qui est important c'est pas tant de dire « ah ben là j'ai pas eu le temps de tout faire » mais plutôt de dire bah oui j'accepte que là il y a de la dette technique et donc oui c'est une potentialité que ça me rattrape un peu plus tard si ça explose pas comme on l'avait pensé mais d'un autre côté en termes d'usage etc bah oui c'est un risque mais que ce risque soit pris de manière intentionnelle et je dirais en tant que produit en fait c'est que du coup même si j'attache à dire que les décisions, les arbitrages sur les problèmes à résoudre doivent être pris par la partie produit Pour autant sur des choix techniques comme ça, je dirais que c'est peut-être une décision, et ça c'est vrai que je ne le dis pas souvent, mais une décision qui devrait être dual, c'est-à-dire prise entre le lead dev et le PM de dire ok, donc le lead dev qui alerte un peu sur ok là je vais devoir faire des arbitrages pour pouvoir te sortir la feature dans deux jours, par contre sache que si je fais cet arbitrage, ça risque de péter là, ou si je fais cet arbitrage, ça risque de péter là, et qu'à deux, et qu'ensuite on porte le fardeau à deux, si plus tard, du coup, il y a le sujet qui revient.

Mathieu : Ce qui est très dur, en fait, côté, je pense, produit. En fait, côté produit, si tu veux le faire proprement, entre guillemets, cet arbitrage, tu as besoin de savoir combien de temps ça va prendre de faire propre. Et en fait, ça c'est un sujet aussi, c'est qu'on est incapable. 90% du temps, on est incapable, on va se tromper tout le temps sur les estimations de ce truc-là. C'est pour ça que tu as besoin d'un couple qui fonctionne où en fait tu vas pouvoir lui dire « ok, bon, prends une journée pour essayer de creuser le truc, d'estimer machin, on voit ce qu'on fait et après on arbitre ensemble ». Parce que le tech, c'est le seul qui est capable de te dire ce que ça fait perdre au quotidien. C'est-à-dire qu'en fait au quotidien, des fois la dette technique te fait perdre du temps. Et que tes produits tu ne la vois pas forcément, tu vois que le truc il prend deux heures, tu ne sais pas si c'est dû à c'est très bien fait mais ça prend deux heures ou en fait c'est parce que le code n'est pas bien fait et du coup en vrai ça prendrait une heure et du coup c'est le tech, c'est le lead qui est capable d'estimer ça. Donc tu es obligé d'avoir pour moi cette discussion entre le produit qui va normalement mieux voir le business, mieux voir la partie roadmap etc. et le lead qui lui va mieux voir qu'est-ce que ça fait perdre au quotidien, quel est l'impact et la pénibilité aussi parce que ça fait partie du truc aussi, travailler sur une base code toute dégueu, c'est pénible en fait, t'es pas forcément fier du travail que tu fais, tu rentres chez toi, tu te dis bon en vrai il y a des gens qui changent de boîte juste parce qu'en fait ils travaillent sur des base code legacy, donc ça a un impact aussi sur les équipes, donc en tant que côté management, côté tech, ça peut avoir un impact qui à mon avis faut prendre en compte aussi.

Terry : Ouais clairement et sur ce que tu viens de dire sur aussi des fois la frustration en travaillant sur du legacy qui est sale. Moi je sais que j'avais toujours une impréhension quand, soit en tant que dev, soit même en tant que PM, mon équipe me disait là ça a été fait n'importe comment etc. Moi je leur rappelais toujours ouais mais il y a 6 mois, il y a un an, quand ça a été fait par une autre équipe, il y avait un contexte différent, ils avaient des enjeux, donc en général aucun dev, aucun ingé aime faire du travail sale. S'ils font du travail sale, c'est qu'il y a des raisons et qu'ils ont dû faire des choix. Et toujours se rappeler aussi quand tu te retrouves face à du legacy plutôt que de PST en te disant comment ils ont structuré le truc, se dire bon, ils ont fait ces choix là, comprendre la raison pour laquelle ils l'ont fait et puis après si tu as plus de temps pour le refaire, aussi du coup prendre le temps pour mieux faire les choses. Mais ça fait partie de la réalité aussi du job et je pense que à ce niveau là, je parlais, si tu es dans une boîte qui fait plus R&D versus business, dans le cas d'une boîte qui fait vraiment, c'est du business, avec Jean de Brigade, il m'expliquait que pour lui, la grosse vision qu'il avait c'est que la tech doit être.

Mathieu : Au service du business.

Terry : Et du coup, si tu as cet état d'esprit, même en tant que dev, en tant qu'ingé, et bien du coup tu vois les choses différemment parce que tu te dis effectivement mon rôle en tant qu'ingé c'est d'avoir une expertise aussi technique donc d'être capable de bien faire les choses mais si je dois les faire vite et bien je dois aussi être capable d'ajuster un peu mes critères ça ne veut pas dire et ça aussi ça me fait rebondir sur un point que tu disais c'est-à-dire que ce qu'on peut voir beaucoup dans l'approche quick and dirty du coup tu vas avoir peut-être des profils pas du tout techs qui se disent bah ça y est je peux devenir dev avec un bootcamp de six mois je deviens dev j'ai jamais fait d'études là-dedans avant on peut apprendre et clairement je suis le premier à dire que voilà si tu veux c'est quelque chose qui est faisable par contre faut pas non plus sous-estimer la complexité du job c'est à dire que c'est pas un bootcamp de six mois qui te forme un ingé qui a fait cinq ans d'études plus des stages des expériences pro et donc là dessus c'est bien si tu veux basculer devenir dev par contre ne te limite pas en fait à cette capacité de faire du quick and dirty Si tu commences à rentrer dans ce métier-là, prends le temps en parallèle du coup, même si ton activité te demande de faire plus du Cook & Dirty, prends le temps de te former au design pattern, aux architectures propres. Mais après, ne deviens pas non plus un ayatollah de dire dans ta boîte.

Mathieu : « Ah, il faut faire comme ça, comme ça, parce que j'ai vu ce.

Terry : Design pattern-là, il faut l'implémenter.

Mathieu : » C'est souvent l'étape suivante, je fais du Cook & Dirty et tout d'un coup, J'apprends qu'il y a plein de trucs. Au début t'es un peu perdu parce que tu sais pas les faire et puis à un moment que tu commences à les appliquer, tu les appliquer partout. C'est ça.

Terry : Et tu te dis mais ma boîte elle est pourrie, ils font n'importe quoi, bon je me barre.

Mathieu : C'est pour ça que c'est important d'intégrer les devs, les ingés. dans la partie produit en fait, dans la partie roadmap. Tu vas essayer de leur faire voir, ok, c'est quoi les problématiques, leur faire parler avec des utilisateurs, parler avec des opérateurs en fait si t'as du back-office, etc. Tout ça c'est important de les intégrer là-dedans parce que du coup tu les... T'en as qui vont être naturellement business-oriented, t'en as d'autres qui vont l'être moins. Et ils vont pas forcément aimer ça, mais il est quand même... Alors j'exagère un peu, c'est-à-dire que tu peux très bien avoir des centres d'expertise technique, c'est d'autres choses, mais c'est quand même bien, je pense toujours que le dev à un moment il soit en face du client, qui comprennent un petit peu ce qu'il fait, pourquoi il le fait. Parce que oui, c'est là où tu dis ok, en fait j'arbitre, là il y a une urgence, là en fait il y a un user pas content qui est en train de gueuler sur tout le monde. Donc c'est pas un bon moyen de faire des choix hors de map, mais au moins tu comprends la pression qu'ont les gens, et tu comprends aussi pourquoi à des moments, bah ok, il faut peut-être résoudre le problème, prendre le temps de bien le faire plus tard. Toujours, c'est toujours le sujet de c'est quand plus tard. Mais voilà, en tout cas arbitrer, je pense ça fait partie du métier de dev.

Terry : Totalement aligné là-dessus, et en fait sur aussi la chose à laquelle ça me fait penser, et c'est vrai que c'est toujours la même chose qui revient, mais sur différents contextes, c'est la notion en fait de collaboration, c'est-à-dire que c'est pas moi je suis la partie tech, je veux faire les choses super bien, c'est mon domaine d'expertise, toi t'es la partie business, fais tes études de marché, fais tes AB test, etc. de ton côté, puis si on connecte les deux ça va être magique et on va faire le produit qui va tout casser. Non, c'est qu'en fait c'est ça qui doit communiquer, travailler en permanence ensemble ces deux mondes, pour réussir à faire les choses bien. Et en fait, comme tu le disais, il n'y a pas de formule magique, il n'y a pas de réponse magique. Si on avait une à donner, pour moi, ce serait la collaboration, c'est-à-dire la capacité en permanence à faire des vases communiqués entre les deux mondes. Ça ne veut pas dire de mettre des devs en face de 10 clients pas contents tous les jours pour leur mettre un coup de pression et leur dire qu'il faut corriger un bug, mais c'est plutôt faire des dépassations entre les deux mondes pour montrer les contraintes de l'un et de l'autre, et ensuite toujours travailler dans cette logique aussi d'alignement et du coup de se dire Ok, on a un objectif commun, c'est de servir notre client et comment on y arrive ? Chacun apportant sa spécificité, mais en ayant conscience des problématiques de l'un et de l'autre. Donc vraiment cet aspect collaboratif, je pense qu'il reste aussi primordial.

Mathieu : Ouais, c'est ça. Et du coup qui, j'espère, te permet de bien placer ton curseur pragmatisme. Si tu n'as pas le client, si tu ne sais pas ce que tu fais, pourquoi tu le fais, forcément ton curseur, tu le mets travail bien fait. Et du coup, je pensais à un truc là sur l'aspect framework de décision. Je crois que c'est d'Hilbert, tu sais celui qui fait des petits cartoons sur la tech, il fait toujours des petits cartoons sur la tech où il fait des blagues. Et il avait fait un petit graph où il expliquait Un autre travers qu'on a des fois quand on est tech, c'est dès qu'il y a une tâche manuelle qu'on peut automatiser, en fait, plutôt que de la faire, on a tendance à aller l'automatiser. Et en fait, des fois, ça prend 5 heures de l'automatiser alors que ça prend 5 minutes de faire la tâche. Et du coup, il y a un petit graphe où il dit en fonction du temps de la tâche et en fonction du temps que tu mets à l'automatiser, en combien d'années c'est rentabilisé. Tu vois, donc ça va de c'est rentabilisé direct à c'est rentabilisé en 3000 ans, quoi. Et c'est un peu pareil avec la dette technique, sauf que du coup, la dette technique, tu as toujours du mal à estimer ce que ça te fait gagner. C'est là que tu ne peux pas bien. Mais c'est un peu ça que tu dois Combien de temps ça va prendre ? Qu'est-ce que ça va faire gagner ? Mais tu vois, c'est pas juste combien de temps ça va faire gagner, c'est qu'est-ce que ça va faire gagner combien de temps ? Qu'est-ce qu'on va gagner ? Est-ce que ça va débloquer des features ? Voilà, il y a plein d'aspects à faire. Et du coup, c'est un peu heuristique, mais c'est quand même ça que tu dois avoir dans ta tête, à la fois en tant que tech et en tant que produit, pour prendre cette décision-là. Tu dois au moins essayer de tenter de faire ça, même si tu n'arriveras jamais, je pense, à avoir les vrais.

Terry : Chiffres, les bonnes choses, etc. Ouais clairement, totalement en ligne à l'issue, c'est vrai que c'est marrant la partie automatisation, ça me rappelle aussi des souvenirs, c'est vrai qu'en tant que dev t'as tendance à se réflexe de dire ok j'automatise ça, mais des fois t'automatise quelque chose qui en fait va être run une fois, donc tu réfléchis à la main en 5 minutes plutôt que de coder en deux heures. Et toujours pareil, notion de collaboration et pareil sur l'aspect technique, ne pas non plus avoir une posture en tant que produit de dire je m'en fous de la détechnique, fais quick and dirty. Et en tant que dev d'avoir la posture de dire il faut que tu me laisses 6 mois sinon on ne va pas avoir un truc propre. C'est trouver, expliquer quel est toujours pareil l'équilibre qu'on va trouver entre les deux et ça passe par la discussion. Tu parles de curseur, curseur ça bouge en permanence. Ce n'est pas un trait que tu mets et qui reste figé pendant des années.

Mathieu : C'est pour ça que la relation de confiance entre les deux, tu vois, product et lead, à mon avis, elle est importante parce que quand tu es product, tu as besoin de sentir que ton lead dev, il comprend le business et quand il fait son arbitrage. Et inversement, quand tu es lead dev, tu as besoin de comprendre que ton product, il comprend tes problématiques à toi en fait. Donc si tu as cette relation de confiance, je pense que tu fais tes compromis et tu arrives probablement à trouver un meilleur placement de ce curseur-là.

Terry : Super, je pense qu'on a fait un bon tour. Est-ce qu'il y a un sujet que tu penses qu'on n'a pas assez creusé ? Non, c'est bien déjà. J'espère qu'on a toujours pas mal de monde qui est en train de nous écouter, qui n'a pas pris peur sur la partie sujet tech. Du coup, pour aller sur mes deux questions typiques du podcast, donc la première c'est une conviction, alors tu en as un paquet mais là il va falloir que tu... que t'en choisisse une ou deux ou trois de convictions fortes que t'as et avec laquelle en général t'es en désaccord avec tes pairs. Tu ne peux pas me parler de la chocolatine qu'on appelle pas un chocolat, on le sait tous à part les gens du sud-ouest.

Mathieu : Alors, je vais du coup te parler d'un seul truc, mais du coup je vais quand même te parler d'un post-LinkedIn là, donc c'est pas la chocolatine. Mais récemment j'ai fait un post-LinkedIn sur les microservices. Donc c'est un sujet très technique, mais peut-être pour essayer d'expliquer. Côté tech, on oppose deux architectures, le monolithe et les microservices. Donc le monolithe, C'est comme si tu disais, je fais une seule application, une seule grosse application, je la déploie toujours en même temps. En fait, il y a un seul truc qui bouge et tous mes développeurs travaillent dessus. Et les microservices, c'est en fait, il y a plein de petites applications, plein de petites applications qui se parlent entre elles. C'est comme une espèce de ruche en fait, où tu as tout le monde qui cohabite et c'est hyper harmonieux, ça marche hyper bien, ça c'est la théorie. Et du coup voilà, j'ai fait un peu ce LinkedIn là-dessus pour dire que, bon pour faire des blagues, pour me moquer un peu des microservices, parce que moi du coup j'ai vécu dans mon ancienne boîte architecture microservices où on a fait, c'était difficile en fait, et donc on a essayé vraiment de passer, pas du jour au lendemain, mais d'un monolithe à microservices. Donc on a fait plein de trucs et en fait, contrairement à ce que l'on essaie peut-être de dire un peu, c'est pas simple. C'est-à-dire qu'en fait il y a plein d'avantages au microservice et du coup là-dessus pour venir sur ma conviction, moi la conviction c'est que 99% des boîtes devraient en monolithe, concrètement. Un truc simple où en fait on se soucie pas de l'infrastructure parce que du coup on opérer des microservices, ça suppose beaucoup de choses techniques derrière, qui souvent ne servent pas le produit. Donc voilà, c'est un peu ma conviction. Je pensais, je dis que beaucoup de gens ne sont pas d'accord avec moi, parce que je pensais que c'était un truc assez acquis, mais apparemment il y a eu des débats enflammés sur Twitter là-dessus, et moi sur le Posting Lean, j'ai vu quand même pas mal de gens qui me sont un peu rentrés dedans. en disant que je ne connaissais rien au microservice. Mais c'était marrant de débattre, il y a eu pas mal de débats là-dessus. Ma conviction c'est que 99% du temps, déjà tu devrais toujours commencer par un monolithe, parce que microservice suppose aussi de découper intelligemment les choses. Et quand tu démarres une boîte, ton domaine, même côté produit, il est un peu flou la plupart du temps. J'exagère, il y a des domaines où on connaît bien, mais la plupart du temps, ton domaine est un peu flou, t'explores. Et donc en fait, le découpage, il faut le faire plus tard. Voilà, sur un truc technique, on pourrait rentrer vraiment dans ce déballage, je ne veux pas forcément en dire plus, mais je sais que ce truc-là fait bondir pas mal de gens, donc voilà.

Terry : Ouais intéressant comme position là-dessus, alors j'ai pas un avis ultra tranché moi sur le sujet mais ce que je pourrais dire c'est que par rapport à ce que tu viens de dire peut-être pour nuancer c'est que en fait c'est pas parce que tu fais du monolithe que t'as pas une architecture un peu propre, c'est-à-dire que ça veut pas dire que t'as un code, t'as tout ton code qui est dans un contrôleur et puis deux autres fichiers puis il y a tout qui... tu peux quand même faire des architectures modulaires sans être en microservice. Et souvent peut-être je pense que de base on se dit pour faire du modulaire faut que je fasse du microservice, sauf qu'en fait c'est un peu prendre un marteau pour tuer une mouche encore une fois, c'est que quand tu fais du microservice, il y a plein plein de contraintes de run sur les infras, de déploiement, d'interconnexion qu'il ne faut pas avoir, donc de fonctionnement stateless, enfin beaucoup beaucoup de choses qui font que ce que tu voulais peut-être à la base c'était juste avoir un code assez modulaire et ça tu peux très bien le faire. dans un monolithe.

Mathieu : Il y a un côté extrême des développeurs qui ressort derrière ça, c'est qu'en fait, ils se disent « au moins avec un microservice, comme c'est des choses séparées, tu as séparé. Tu es sûr que personne ne va venir faire du code qui va mixer deux microservices ». Et donc ça, certes, c'est vrai, mais la contrepartie, c'est que t'as aussi créé des frontières qui sont beaucoup plus dures à casser que dans les modules monolithes, t'es beaucoup plus flexible au niveau du code, au niveau des changements que tu peux faire. Et donc effectivement, c'est exactement ce que tu dis, dans un monolithe, tu peux faire des modules séparés qui reflètent finalement ce que t'aurais fait en microservice, t'as pas la contrainte dure, c'est qu'il y a toujours quelqu'un qui peut venir modifier le code, mais normalement, bon voilà, normalement t'as des équipes en interne, t'as des gens, t'essayes de ne pas prendre des décisions tout seul dans ce que tu fais, et t'es censé le gérer comme ça. Mais oui, toujours quelqu'un pourra faire un truc qui va à l'encontre de ce que tu aurais figé dans le marbre si tu avais fait des microservices.

Terry : Du coup la boucle est bouclée sur le sujet juste avant du pragmatisme, c'est-à-dire que dans une architecture monolithe, même si derrière ton code est modulaire, Si jamais il y a un moment où il faut faire du quick and dirty sur un sujet, tu vas pouvoir accéder à ton module que tu aurais dû accéder d'une certaine manière, de manière plus sale, parce que tu sais qu'il faut rapidement sortir de ta fonctionnalité que tu n'aurais pas pu faire si tu étais dans un mode complètement microservice. Top. Et du coup, dernière question sur les recours. Tu en avais déjà donné pas mal lors du premier échange.

Mathieu : Oui, j'en ai encore plein. Les recos... Alors, je vais te donner un livre qui est une fiction, mais que si les gens aiment les romans, la fiction, tout ça, je pense qu'il serait cool d'avoir lu. Ça s'appelle La Horde du Contrevent. Je ne sais pas si tu connais. Moi, c'est mon roman... C'est le meilleur bouquin que j'ai jamais lu, concrètement. Et du coup, c'est de la fiction. C'est de la science-fiction. Mais souvent, la science-fiction, on pense que c'est un peu froid, pas très bien écrit. Là, c'est de la science-fiction écrite par quelqu'un qui a un vrai talent littéraire, donc vraiment hyper bien écrite. Et donc, c'est l'histoire d'un groupe de gens qui, tous les ans, on forme un groupe de gens pour remonter sur une planète, parce que c'est une planète qui est en pente. et il y a du vent, il faut remonter, on sait pas ce qu'il y a au bout de ce truc. Et tous les ans, il y a une équipe qui est formée, des gens complémentaires, avec des spécialités différentes, etc., qu'on appelle une horde, qui sont formées tous les ans, et jamais personne a réussi à atteindre le bout de ce truc. Et donc c'est l'histoire d'une de ces hordes, et c'est... Enfin voilà, moi je... Tu peux avoir du mal avec peut-être les dix premières pages, etc., enfin bon, c'est particulier, mais c'est vraiment hyper bien écrit, c'est un truc... Voilà, donc ça c'est un... Si vous aimez lire, c'est très chouette. Un bouquin que je trouve assez fou aussi, qui n'est pas de la fiction pour le coup, mais on dirait que c'est de la fiction, c'est Bad Blood sur Theranos. Theranos, c'est cette boîte américaine avec Elizabeth Holmes, qui était l'assistante de ce truc-là, qui a été encensée pendant longtemps, ils avaient promis de révolutionner le test sanguin. Donc il y a plein de choses derrière hyper intéressantes, ne serait-ce que sur la santé. Et donc Bad Blood, c'est un peu l'histoire de cette boîte, écrite par un journaliste du New York Times, tu crois ? Et c'est mieux qu'un roman, c'est-à-dire que tu lis ce truc, c'est un thriller, tu te dis mais comment c'est possible que ça va forcément s'arrêter un moment cette histoire. Donc moi je trouve ça hyper intéressant, je trouve ça hyper intéressant sur la psychologie notamment des gens qui... donc Elisabeth Holmes, c'est son CEO, là je sais plus comment il s'appelait, comment il s'appelle. leur psychologie à eux, comment tu peux emmener quelque chose aussi loin avec, entre guillemets, autant de malhonnêteté intellectuelle et comment ça peut passer. Donc c'est hyper intéressant et peut-être un bouquin plus business. Récemment j'ai lu Build de Tony Fadel qui est le père de pas l'iPhone, l'iPod. Hyper intéressant sur plein de sujets. Mais du coup, lui, c'est toute son expérience de startup. Donc, il a été à la tête du département iPod chez Apple. Il a fait pas mal de choses. Il a créé une boîte sur des thermostats qui cartonnent. On ne dirait pas comme ça, mais voilà. Et très, très intéressant sur le management, sur être CEO dans une boîte, sur tes choix de carrière, voilà. Vraiment passionnant.

Terry : Super. Merci pour ces ressources et puis merci pour ton partage et ton temps, Mathieu.