Spaghetti to Bento #4 - Yoan Thirion

Invité : Yoan Thirion

Au programme :

Ressources partagées par Yoan :

3 devs qui l'inspirent :

Et pour en savoir plus sur Coda : https://www.coda.school/campus/dijon.

L'épisode

Le podcast

Spaghetti to Bento

Transcription

Yoan Thirion

Hey Alexandre, ça roule ?

Alexandre

Salut Yoan ! ça va ?

Yoan Thirion

Ouais, ça roule. Bien fatigué. Mais ça va. Et toi ?

Alexandre

Ça va. T'as enchaîné ces derniers temps ?

Yoan Thirion

Ouais, ouais, j'enchaîne beaucoup là. En fait, j'ai déjà commencé Coda. Et je fais ça en plus de mes activités. Pendant quelques mois ça va être compliqué, le temps que je clôture et que je parte de la Suisse.

Alexandre

Ok. Vas-y je te reposerai des questions dessus.

Yoan Thirion

ça marche.

Je cherche des intervenants si jamais.

Alexandre

À distance aussi ?

Yoan Thirion

Non, c'est physique par contre, c'est à Dijon.

Alexandre

Ok. Parce que je suis plus en Normandie. Et là je vais bouger au Vietnam.

Yoan Thirion

Pendant plusieurs mois ?

Alexandre

Ouai. J'ai pris juste un aller simple. Je n'ai pas un plan très précis. Mais j'ai envie de voyager.

Yoan Thirion

Tu veux t'installer là-bas ?

Trop bien. J'ai fait la Thaïlande il quelques années, c'est bien. J'y suis resté un mois. Par contre, il y a deux ans maintenant, on est resté six mois en famille à la Réunion. On a arrêté de bosser complet.

Alexandre

C'était quoi votre programme du coup là-bas ? Est-ce que l'objectif était de voyager ? de faire des trecks ?

Yoan Thirion

C'était surtout de faire un break. On a eu l'opportunité de la faire. A l'époque, je bossais au Luxembourg et j'avais droit à un congé parental de six mois que je n'avais pas pris à la naissance de la petite. Ce qui fait que c'était l'occasion, avant que je quitte le Luxembourg, de le prendre. Et puis ma femme à l'époque, quand c'était le Covid, a été mise à la porte.

Alexandre

Ok.

Yoan Thirion

Ce qui fait qu'elle enchaînait un peu les petits boulots. Du coup on se dit : "bah vas-y, on n'a rien qui nous retient, on va faire un tour à la réunion".

J'ai un très bon ami qui habite là-bas et mon beau-père est originaire de là-haut. Alors ma femme ne connaissait pas la famille qu'il y avait sur place, elle les avait jamais vues, mais on s'est dit que c'était un bon moyen de faire connaissance avec les gens sur place et de kiffer un peu. Donc il avait pas plus de choses que ça, juste du kiff.

Et revoir la vie un peu différemment.

Alexandre

Ok. Tu te serais vu travailler de là-bas ?

Yoan Thirion

Sur place, je me suis mis en contact avec une école, avec Epitech. Je me suis fait un ami avec le boss d'Epitech. On a fait deux-trois meet-ups. Je suis allé aux événements qu'il y avait sur place, techniques, aux événements tech.

Et j'ai été surpris en fait. Parce que la Réunion, tu peux te dire, ouais, c'est une île un peu éloignée. Déjà qu'en France le niveau n'est pas forcément fou, les gens ne pas passionnés ...

Mais eux en fait, ils sont à distance. Souvent, ils viennent en France pour finaliser leurs études, ils trouvent des boulots en Europe, et vu qu'ils veulent absolument retourner à la Réunion, ils sont motivés. Je ne vais pas dire passionnés, mais ils sont à minima motivés par trouver des clients en Europe et pour pouvoir repartir à la Réunion. Ils sont dans l'optique de : il faut que je sois bon, que je me démarque, et du coup, tu as des devs qui sont vraiment bons.

Je ne m'attendais pas à ça quand je suis arrivé à la réunion pour être honnête. Dans les événements, il y avait un niveau de discussion qui était beaucoup plus élevé que ce que je peux avoir dans des événements en France.

J'aurais pu bosser là-bas, ça aurait peut-être pu être intéressant. Mais t'as vite fait le tour d'une île. Au contraire de l'Asie, une île, c'est tout petit, quoi.

Alexandre

Ok. Ils ont plus la niaque. Et après ils bossent en remote avec l'Europe.

Yoan Thirion

Ouais. Après il y a des entreprises locales, mais la plupart des dev que j'ai rencontrés étaient freelance et ils bossaient pour l'Europe. Le décalage horaire n'est pas méchant. Donc ils arrivent à bosser comme ça et ça marche plutôt pas mal, enfin à l'époque. Là ça s'est peut-être un peu dégradé avec le conjoncture économique et la chute pour les freelances.

Alexandre

Ouais.

Yoan Thirion

Je sais pas s'ils sont impactés beaucoup ou pas. Il a quand du dynamisme local. Je suis allé donner des cours à l'hépitec là-bas. Les jeunes, enfin pas tous comme dans toutes les écoles, mais il en avait, ils m'ont surpris. Ils étaient en troisième année. Ils s'étaient lancé un défi : tous les mois une idée produit qu'ils essayaient de matérialiser. Ils étaient 3 à faire ça. Il en un qui jouait le rôle de Scrum Master puis ils se mettaient en mode sprint de deux semaines. Le but, c'était d'itérer le plus rapidement possible sur leur idée.

Et ces trois-là ont réussi à percer. Ils ont fait un truc pour le département de la réunion. Ils ont réussi à vendre une de leurs idées, se faire sponsoriser, se faire financer, monter une boîte, etc.

Alexandre

Oui.

Yoan Thirion

Il y avait de la motivation quoi. Plus de Niaque effectivement.

Alexandre

J'ai l'impression qu'en France, on est quand même assez passionné, un peu geek sur les pratiques. Tout ce qui est craftsmanship, j'ai l'impression que ça accroche bien en France. Est-ce tu as cette vision-là ? ou pas ?

Yoan Thirion

Je ne sais pas. Chez mes clients, ça pêche tout le temps. Enfin, ça dépend. Si tu vois un event de craft, c'est sûr que les gens sont motivés, ce qui sont leur plein gré. Mais en entreprise, ce que j'observe, c'est que ce n'est pas la majorité. J'ai déjà eu des moments dans ma vie où j'étais obligé de justifier, d'écrire des tests automatisés. Ou bien de devoir se justifier de mettre en place une librairie alors que ça te fait gagner énormément de temps quand tu fais tes accès DB à la main. J'ai beaucoup vécu ça chez mes clients. Et je le vois encore à l'heure actuelle.

Le côté craft, je le vois bien sur les réseaux sociaux. Les gens essaient d'en parler, etc. Il y a une surreprésentation. Certains essaient de faire le buzz, en plus et il en a qui essaient de clasher. Donc c'est pas mal représenté. Après en entreprise, très sincèrement, vois rarement ces pratiques mises en place ou comprises, et ne serait-ce que de l'intérêt pour. Je trouve qu'il y a une vraie divergence à dessus.

Alexandre

Sur les tests, c'était quoi qu'on t'opposait ? C'était quoi la peur derrière ?

Yoan Thirion

Alors ça dépend du contexte. Sur celui que j'ai en tête, l'architecte avait peur des personnes qui ramènent des choses de l'extérieur. Il voulait avoir la main mise sur tout ce qui passait. Il y avait un architecte pour la banque qui était MVP Microsoft. En réalité il MVP de rien du tout. Et il avait peur. Il tirait dans les jambes des gens. Il n'était pas là en support. Lui disait que ça n'avait aucun intérêt d'écrire des tests. Donc c'était la vision d'une personne qu'il imposait à toutes les équipes.

Derrière, il y avait de l'ego. Ça ne venait pas de lui donc c'était de la merde. Il ne prenait pas à ces pratiques-là, du coup, c'était forcément pas bien. Il était un VP Microsoft et il ne se sentait plus. On lui avait donné un badge. On lui avait donné un badge de shérif. C'est comme les enfants, quand tu lui donnes un badge de shérif à un gamin de 7 ans, il va jouer au shérif.

C'est ce qu'ils ont fait dans cette banque. Il n'était pas bon, mais il se croyait bon, et il défonçait tout le monde.

Après, sur l'accès aux données, c'était un gars qui avait développé tout le système d'accès aux données. C'était pour du calcul d'optimisation de routes physiques de télécommunication. La problématique ici, c'était que la personne avait développé pendant des années la couche d'accès aux données. C'était son bébé en fait, et il voulait que tout monde l'utilise. Seulement c'était incompréhensible du point de vue extérieur. Lui s'y retrouvait car c'était lui qui l'avait développé. Mais c'était incompréhensible par tous.

On a été intégré à leur repository et à leur manière de faire, mais on était à part. On avait mis en place de l'Entity Framework - qui vaut ce que ça vaut, je ne suis pas un grand fan d'Entity Framework pour le coup, mais ça nous permettait de faire des accès données sans avoir à se triturer le cerveau. Lui pour faire ses trucs, il y avait de l'imbrication d'objets, etc. C'était vraiment son bébé.

Il avait la certitude de que "mon truc est mieux que ce que vous pouvez amener avec des outils".

Pour casser ça, ce qu'on a essayé de faire à l'époque, c'était de faire du benchmarking. Et on lui a démontré que malgré les couches de mapping objet, on arriverait à plus performant que son code.

Encore une fois, c'est l'ego qui est venu parler et ça s'est mal passé.

Alexandre

Alors, c'est marrant, mais aujourd'hui, j'aurais tendance à utiliser des requêtes SQL brutes, en particulier sur la couche lecture. À voir les projets, mais en première intuition, je partirais plutôt là-dessus. Je vois ça comme plus simple qu'un ORM. Un ORM te rajoute une couche d'abstraction, mais aussi une couche de complexité par-dessus.

Les requêtes SQL, c'est pas très beau, mais c'est simple, c'est des objets qu'on comprend, assez fondamentaux.

Après peut-être que si tu as 15 tables, que tu dois faire des jointures de jointures dans tous les sens, peut-être qu'un moment ça devient trop tordu.

Yoan Thirion

Oui. Je n'ai pas de garde de chapelle là-dessus. J'ai beaucoup utilisé des micro-ORM ou des tiny-ORM, des choses comme Dapper, Petapoco, ce genre de choses qui te permettent d'être plus proche de la DB. Effectivement, je n'aime pas la génération automatisée d'Entity Framework. Ça te rajoute une complexité de malade. Quand tu veux débuguer une query, comprendre ce qui se passe, la query est juste illisible.

Cette couche de mapping là, elle rajoute une grosse complexité. Tu as raison de le mentionner.

Alexandre

Parfois, tu perds un peu la compréhension de ce que tu fais.

Yoan Thirion

Ouais, carrément. Tu perds la maîtrise.

Alexandre

En ce moment je reviens de plus en plus aux outils clis (clients). Plutôt que d'utiliser l'interface, dès que je peux, j'essaie d'utiliser le cli. Parce qu'en général, tu es plus proche des concepts et de la logique qu'il a derrière. Je crois pas que c'est toujours plus rapide. Parfois, c'est plus lent. En fait cliquer ça va vite. C'est tellement rapide, clique, clique, clique. Mais le cli, je trouve ça plus fun et j'ai l'impression que tu comprends mieux ce que tu fais.

Yoan Thirion

Ouais, il y a un truc autour de la maîtrise là, clairement.

Alexandre

Ok.

Peut-être qu'on peut reprendre la trame.

Je te présente, et on passe aux questions ?

Yoan Thirion

Haha. Ça marche. Ça roule, oui.

Alexandre

Parmi tes contributions notables : - Tu as fondé Software Craftsmanship Luxembourg en 2020, que tu as hosté pendant deux ans avant de passer la main à Guillaume. La chaîne YouTube rassemble 38 présentation avec des super invités : Sandra Mancuso, Vladimir Koryakov, Adam Tornhill, Nicolas Carlo, pour citer quelques-uns. - Tu as créé Advent of Craft avec Yann Courtel en 2023. Vous avez fait deux éditions, et c'est un calendrier de l'avant introduit aux pratiques de développement. Vous couvrez plein de concepts, behavior driven design, mutation testing, property based testing. - Et tu es speakers depuis 2017. Tu as partagé plus de 60 decks. - Tu as créé plusieurs bases de connaissances en ligne. Il y a Xtreme TDD qui est une base communautaire accompagnée de Katas, et ta base perso qui est hébergée sur le gitbook. - Enfin, tu as toujours plein de ressources pour illustrer tes propos et tes concepts.

En tant que consultant en tech, j'imagine que tu souvent appelé pour des problèmes de legacy. C'est quoi les derniers problèmes sur lesquels tu as été appris dans tes dernières missions ?

Yoan Thirion

Il ne va pas y avoir de grosses révolutions dans ce que je vais pouvoir te dire. C'est principalement des problèmes de qualité, la perte de maîtrise justement, on parlait tout à l'heure de maîtrise. C'est vraiment ça, c'est le sentiment de plus du tout être en maîtrise. Le coût des fonctionnalités qui a largement augmenté. Le fait que l'équipe soit plus en confiance pour apporter des modifications. Là c'est ce que je vis chez un client.

En gros, je fais une modification à un endroit, ça va casser potentiellement à 3, 4, 5 autres endroits. Ça, c'est souvent les problématiques qui sont identifiées, et c'est là-dessus que j'interviens.

Et je dois avouer que les diagnostics c'est souvent les mêmes : c'est le manque de qualité, le code spaghetti qui fait que la maintenabilité n'est pas présente.

On a souvent un legacy qui s'est accumulé avec la théorie de la brisée qui s'est perpétuée. La théorie de la vitre brisée fair référence à une expérimentation qui a été faite. Si une vitre était cassée à un endroit, on se rendait compte que rapidement d'autres vitres allaient être cassées. Par contre, si on la réparait rapidement, on se rendait compte que les gens se retenaient de casser d'autres vitres.

C'est un peu pareil dans le code. Si on laisse du code de mauvaise qualité à un endroit, ce code-là, il a des chances de devenir une norme.

D'ailleurs, petite expérimentation que je fais en ce moment avec Claude Code, c'est exactement ce qui se passe avec les Gen.ai qui étudient ton contexte. Si tu as code qui est de faible qualité, on va dire d'un point de vue X, il va répliquer ça dans tout ton code.

Alexandre

Quand tu arrives dans une équipe comme ça, comment est-ce que tu fais ton diagnostic ? Tu interviewes les gens, tu relis le code, tu as un processus ?

Yoan Thirion

Oui.

Je pourrais t'envoyer le lien d'ailleurs. J'avais fait une interview avec les amis de Packmind sur la question.

S'il a une équipe qui est identifiée comme ayant des problèmes, je n'y vais pas en mode paternaliste en leur disant « c'est comme ça qu'il faut faire ». Ce que j'ai envie de poser, c'est une prise de conscience d'où est-ce que collectivement, on a des axes d'amélioration.

Pour ça, je fais un atelier de kick-off avec l'équipe dans lequel on apprend à se connaître et on identifie les axes d'amélioration perçus par l'équipe. Pour faire ça, je leur demande, sur des catégories que j'identifie comme primordiales de diagnostiquer l'état.

Les catégories sont par exemple la qualité du code, la qualité des tests, la facilité de déployer le système, l'opérabilité du système, etc.

J'ai des définitions de ça veut dire quoi être dans le rouge, ça veut dire quoi être dans le vert. Je leur demande de manière collective de voter. C'est un vote secret entre guillemets : à 3, je leur demande de révéler la carte. "Vous, pensez qu'on est plutôt dans le vert ou pensez qu'on est plutôt dans le rouge" ? Et chacun peut s'exprimer à ce moment-là.

L'idée, c'est de croiser les regards.

Sur certaines catégories, il en a qui vont voir "on est dans le vert niveau clean code", et d'autres qui vont dire, "on est dans le rouge". Le but, c'est de créer un dialogue et d'identifier ce qui fait que vous en êtes là.

ça, permet de poser un constat. Et derrière, ceux qui ont voté rouge, ils voient des axes d'amélioration, donc ils sont déjà identifiés. ça permet de créer de l'alignement, parce que rarement dans les équipes, il y a des moments où il a de l'échange autour de "c'est quoi nos pratiques de dev", "comment on design les choses de manière correcte", "ça veut dire quoi un bon code", "ça veut dire quoi un bon test", etc. Le kickoff permet de créer un momentum autour de ça.

Et les axes d'amélioration, j'essaye de les amener à eux à en trouver. Et souvent, ils ont des idées d'expérimentation. "J'ai entendu parler de ça, qui pourrait nous aider à résoudre ce problème-là", ...

Moi, j'essaye d'y coller mes observations sur base de ce qui a été dit et de ma compréhension du contexte. Et vais croiser avec cela avec ce que je peux observer dans leur code.

Je leur demande d'avoir des accès à leur code. C'est sur base de l'autorisation. Je ne me permets pas d'aller voir les choses sans le dire. Donc sur base de l'autorisation, soit je le mets à côté de quelqu'un, soit il me donne accès à un repository. Et puis je vais naviguer à travers leur code et je vais leur faire un petit audit que j'aime bien appeler une CRAAS. Une Code Review As A Service.

Donc pour une CRAAS, code reviewer as a service, je me mets dans l'optique de je suis nouveau, j'arrive dans votre équipe, qu'est-ce que j'arrive à comprendre d'un de vos repo.

Je regarde tout de l'extérieur et puis je vais jusqu'au plus fin. Le but, ce n'est pas être ultra exhaustif, mais c'est de me dire dans une période d'une heure, qu'est-ce que j'arrive à détecter dans votre code.

Pour ça, je commence par me me demander : - qu'est-ce ce qu'il y a dans le README ? - est-ce que j'ai accès facilement à votre chaîne d'intégration continue ? - Est-ce qu'il a des badges ? - C'est quoi la qualité des commits ? - Est-ce qu'il a de l'analyse statique de code ?

Si oui, j'investigue ce qu'il y a derrière. Sinon, je vais essayer de brancher quelque chose dessus.

Et ensuite, je vais dans le code. Je commence à regarder l'architecture. Ensuite, je vais dans les tests. L'architecture, ça va être le design de la solution, les répertoires, les dépendances. Ça va me permettre de comprendre un peu ce qui se passe, d'analyser avec quoi est interconnecté le système.

Et puis derrière, je vais aller plus granulaire. J'essaie d'identifier des cas de test, du code de test qui me paraît améliorable. Leur manière d'utiliser les test automatisé, la pyramide de tests qui est en place. Je vais voir comment est structuré le code de production, essayer d'identifier des patterns.

Le but, encore une fois, ce n'est pas de venir et dire "il faut tout changer". C'est de dire "j'observe ça", "qu'est que vous diriez de ça", et amener un côté expérimental.

Enfin on regarde la code review que j'ai pu faire en mode outside-in, de l'extérieur vers l'intérieur, plus l'auto-évaluation. Je leur fais une restitution. On parle collectivement de, mes découvertes et de qu'est-ce qu'on fait avec ça. On en sort un backlog de choses qu'on a envie d'expérimenter. Et on déroule avec.

Souvent, on se prend un temps d'expérimentation en dehors de leur code de production. Si on identifie qu'une pratique de test comme de l'Approval Testing peut amener du mieux, parce qu'ils ont beaucoup de fonctions pures, qu'on pourrait faire des snapshots et aller rapidement mettre du code sous test, mais qu'ils ne connaissent pas la pratique. On va faire ça en dehors de leur code de production avec un Kata. On va monter en compétence sur une pratique de dev qui peut leur amener du mieux. ça c'est une première heure ou deux heures qu'on va faire en atelier.

Ensuite, on va passer du temps en MOB, donc tous ensemble en équipe, on va passer du temps tous ensemble pour mettre en place la pratique qu'on a vue en mode safe en mode kata, cette fois dans leur code de prod.

Alexandre

Ok. Parce que toi, quand tu interviens, t'es pas à 100 % avec l'équipe, t'es là le matin, tous les matins ?

Yoan Thirion

Non.

Alors ça dépend des contextes. Dans des contextes, ça va être une demi-journée par semaine ou une journée par semaine, des fois même moins. ça dépend de la volonté de l'équipe, du management, du budget. Dans l'idéal, ce qui est bien, c'est d'avoir des points réguliers.

Quand j'étais dans un gros contexte, on était une petite équipe de coach tech. Ce qu'on faisait, c'est qu'on avait un suivi beaucoup plus régulier avec les équipes et ça portait ses fruits. On avait des demi-journées qui allaient dans l'agenda des équipes et on itérait sur leurs codes ensemble.

Sur base de ce qu'on découvrait, ça nous permettait de préparer des futurs katas pour leur amener d'autres concepts. Dans un des contextes, il y avait un truc autour de comment on fait de l'injection de dépendance. Ils utilisaient du singleton partout et ils se rendaient compte qu'ils avaient de la contention au niveau de leurs accès MongoDB.

Parce qu'il n'y avait qu'une seule instance du repository Mongo alors qu'on pourrait l'injecter manière transciante. En fonction des problématiques qu'on peut identifier avec eux, leur manière de faire, ça nous permet d'ajuster. Le mieux c'est d'être assez présent dans le quotidien des équipes.

Alexandre

Pour toi le rythme idéal serait quoi ? Il serait deux demi-journées par semaine ? ou une demi-journée tous les jours ?

Yoan Thirion

Sur un truc intensif, ça serait top une demi-journée tous les deux jours, quelque chose du genre. C'était ce que j'avais dans un contexte, mais j'ai pas réussi à le reproduire depuis.

Souvent dans les contextes où je vais, il a beaucoup d'équipes, et il y a une volonté de tout commencer en même temps. Je n'arrive pas à faire passer ce message-là de d'abord se focaliser sur un petit périmètre pour ensuite étendre. Souvent, les boîtes ont envie de tout commencer en parallèle.

Alexandre

Ok.

Yoan Thirion

Mais c'est peu souvent la bonne idée.

C'est pour ça qu'en parallèle des initiatives équipes, j'essaye toujours d'avoir une initiative plus large, soit communauté de pratique, soit tech lead. D'avoir une petite communauté de gens qui vont faire les relais dans les équipes. Donc prendre du temps avec des personnes de manière très ciblée pour s'aider sur ce qu'on voudrait voir en termes de pratique, en termes de comportement dans le code, et puis ensuite de faire en sorte qu'il y ait d'autres personnes qui puissent faire leur relais quand je ne suis pas présent.

Alexandre

En général, tu arrives à comprendre le code ? Tu arrives à comprendre ce fait le métier ? Ou des fois, tu es sur des codebases, et tu te demandes juste "mais qu'est-ce qu'il se passe là-dedans" ?

Yoan Thirion

C'est un mix de tout. Ouais, ça me parle bien ce que tu viens de dire sur "qu'est-ce qui se passe là-dedans". Souvent, la question que je me pose moi, "qu'est-ce qui se passe là-dedans", elle est aussi vraie pour l'équipe en fait. C'est que si je ne le vois pas, je ne perçois pas le métier et je dis pas que je suis plus intelligent que les autres ou quoi que ce soit, mais je devrais à minima percevoir des concepts business. Et il y a des moments dans les codes base où tu ne perçois rien en fait. Tu as l'impression que c'est que du CRUD.

Tu te demandes où est la logique. Elle est dispatchée à droite à gauche. Et quand tu commences à pointer ça à l'équipe, tu te rends compte que même pour eux, c'est flou. En fait, ils ne comprennent pas dans quoi ils sont imbriqués.

J'ai bossé pour un gros projet. Il y avait 500 personnes dessus - on va dire environ 400 devs. Et chaque équipe qu'on voyait, c'était un petit morceau de la value stream, de la chaîne de valeur.

Par contre, aucune des équipes n'avait la big picture, ne comprenait comment ils s'inséraient dans la chaîne de valeur. En tout cas, la plupart n'avaient pas cette vision-là. On est arrivé dans des équipes où ils avaient un petit tronçon, et ils ne comprenaient pas ce qu'ils faisaient. Ils avaient des trucs en entrés avec quoi faire des traitements. Et il y avait pas mal de turnovers, ce qui n'aidait pas. Et ça se ressentait dans le code. Donc là, la stratégie qu'on a pu avoir à l'époque avec des gens comme Julien et Nicolas, que je salue s'ils sont présents, s'ils écoutent à un moment donné, Jordan, Gaspar, c'était de repartir aux bases et de repartir de "c'est quoi le fonctionnel", d'inviter des personnes fonctionnelles, et de faire un atelier de d'Event Storming qui permettait de re-clarifier c'est quoi notre scope business.

Alexandre

Ok, donc recréer la big picture et la partager.

Yoan Thirion

Exactement. Re-comprendre un peu. Souvent ça se perd en fait. Et surtout dans les boîtes où il a du turnover. Là, il y avait un énorme turnover pour le coup. ça se ressentait énormément sur le code.

Alexandre

Ok. Si quelqu'un connaît bien le métier, tu peux aller voir cette personne-là, mais si il n'y a personne, vous le recréez.

Yoan Thirion

C'est ça. Et c'est aussi quelque chose de pour casser le silo. Le potentiel silo est encore souvent présent entre entre business et l'IT. Il y a aussi ce truc-là.

Je vois des gens - là j'ai un contexte en tête - où les développeurs ne veulent pas parler au métier. Ils ont des questions, mais ils préfèrent implémenter sur base d'une conviction floue plutôt que d'aller parler à une personne. Il y a vraiment cette crainte encore qui est très présente d'aller poser des questions.

Alexandre

Est-ce que c'est parce que le métier est difficilement accessible ? Ou est-ce autre chose ?

Yoan Thirion

Une peur du jugement, j'imagine. De ce que je peux voir derrière, il y a quelque chose de « tu devrais savoir », on te paye pour savoir, donc c'est à toi de savoir. Mais en réalité, je ne peux pas connaître votre fonctionnel.

Pour moi, il y de ça. Il y a de la peur du jugement de l'autre. Ce qui fait que ça aide pas.

De ce que j'ai vécu en tant que dev, les meilleurs périodes d'agilité que j'ai pu avoir, c'est quand j'allais m'assoir en directement avec le métier. Je prends souvent cet exemple-là, mais j'ai travaillé pour une assurance vie. On devait refaire tout le module de calcul de situation. Et ils envoient des rapports d'évaluation. On devait migrer le rapport d'évaluation qui était implémenté en VB6 vers une nouvelle plateforme.

Le vb6 était en mode très spaghetti. Il y avait des centaines de milliers de lignes de code, c'était incompréhensible, donc on était reparti du métier. L'actuariat, c'est un métier assez dur. Vous faites un calcul de situation, un rapport d'évaluation, ça demande de prendre en compte les paramètres produits, les paramètres risques, l'étape de mortalité, etc. C'est assez volumineux en termes de calcul et en termes de lissage mathématique.

On voulait vraiment repartir du métier et pas faire du un pour un avec ce était fait. Donc là, j'ai bossé complètement avec l'actuariat et je pair-programmait avec l'actuaire à côté de moi, le responsable de l'actuariat. Et ça, c'était top. C'est comme ça, ok, je mets ça, etc. C'est des personnes qui viennent des maths. Donc même s'ils ne comprennent pas tout ce qui se passe, ils te challengent très rapidement.

Alexandre

Est-ce qu'il y a des pratiques que tu considères comme des mauvaises pratiques, que tu as vu en place dans des équipes, et tu te dis que finalement ça a l'air de marcher, elles ne posent pas tant de problèmes que ça.

Yoan Thirion

Ouais, il en a plein qui me viennent en tête. Après, ça serait présomptueux de dire que j'ai considéré ça comme des mauvaises pratiques. Je vais plutôt faire l'inverse alors si ça te va. Plutôt dire une bonne pratique que je considère moi comme une mauvaise parce que je l'ai mal introduite.

Par exemple, c'est un retour d'expérience que j'aime bien faire. Dans une banque, on avait voulu introduire une librairie qui s'appelle vavr et qui permet de faire du fonctionnel en Java, d'amener du paradigme fonctionnel en Java. On s'est enflammés avec à vouloir pousser l'usage de cette librairie-là. On avait fait des ateliers pour faire monter en compétence les gens sur c'est quoi une monade, comment l'utiliser, etc.

Et en fait ça nous a vite dépassé. Ils ont imposé ça dans leur base de code. En gros, on faisait des petites sessions d'initiation, mais on n'avait pas la capacité de suivre au jour le jour tout ce qui se passait, etc. On s'est retrouvé avec des bases de code qui devenaient complètement in-maintenables parce qu'il y avait plein qui ne comprenaient pas ce qui se passait. Ils mélangeaient du fonctionnel avec du procédural. Tu te retrouvais avec du code, tu avais un map et dedans 25 switch cases, imbriqués les uns dans les autres, avec des trials dans tous les sens, etc. Gros échec.

On a voulu venir avec un truc parce qu'on était enthousiastes, par contre, on n'a pas du tout amené le volet vigilance qui était nécessaire de dire, à utiliser, si tous les membres d'équipe sont à l'aise avec et que si vous maîtrisez réellement la chose. Et il y a sûrement des étapes avant d'implémenter ça dans une base de production.

Ce qu'il s'est passé, c'est qu'un mois plus tard, on a été appelé en urgence. Les devs avaient tellement usé le truc sans comprendre forcément le pourquoi ni le comment, qu'on se retrouvait avec des tests qui étaient passés de 30 secondes d'exécution pour toute une suite de tests avec du Spring Boot etc, à plus de cinq minutes, parce qu'ils ne maîtrisaient pas. ça lançait des exceptions, ils n'en étaient même pas conscients, etc. Il y avait plein de problèmes dans leur base de code et vraiment un retour d'expérience si on veut intégrer des nouvelles pratiques, des nouveaux concepts, ça demande de s'assurer que les gens soient en capacité de le faire. Et là on a été beaucoup trop enthousiastes. À refaire, je ne ferai plus ça.

Avant d'être maîtrisé un concept comme celui-là, faut le pratiquer pour que ça s'ancre dans notre mémoire à long terme, pour qu'on le comprenne bien, etc. Et ça n'a pas du tout été fait.

Alexandre

Oui, peut-être commencer sur une part de la codebase, mais ne pas l'étendre partout au début.

Yoan Thirion

Exactement. Et sur un truc plus safe ou même dans un side project à côté qu'on fait évoluer collaborativement avec les personnes. Si vous prévoyez pas d'embarquer le reste de l'équipe, ça va se retourner contre vous. On pensait que ça allait couler de soi et ça a été un vrai apprentissage pour nous.

Alexandre

Et du coup, comment est-ce qu'ils s'en ont sorti ? Vous avez rollback les changements ?

Yoan Thirion

On a été un peu en mode pompier pour les aider à remettre le code d'équerre.

Alexandre

OK. Avec vavr ou vous avez retiré la lib ?

Yoan Thirion

ça dépendait des équipes.

Il y en a dans lesquelles on a complètement supprimé.

Il en a d'autres qui ont voulu garder quand même, parce qu'ils se disaient que ça amène de la valeur, ça peut amener plus de lisibilité dans le code, plus de prédictabilité. Ça nous amène un plus, donc on a envie de le conserver. Surtout qu'on avait fait, alors c'était surtout Alex, mais il y avait une couche d'expositions, une couche de mapping aussi pour remonter sur Spring Boot, un vavr, par exemple, on le re-mappait dans un code HTTP, etc.

Il avait des facilités d'usage qui étaient mises en place. Donc ça, on voulait le conserver.

Pour certains, on a fait du rollback, on va dire. Et pour d'autres, on a les aidé à itérer dessus.

Je ne sais pas où ça en est à l'heure actuelle. ça fait cinq ans que je ne suis plus chez eux. Mais voilà, un apprentissage et un exemple d'une bonne pratique (pour moi), d'avoir du code qui est plus explicite avec du code plus fonctionnel, mais poussé à l'extrême et sans accompagnement, a fait que cette bonne pratique-là, dans ce contexte, ça a très vite détérioré la situation.

Alexandre

Comment tu mesures le succès d'une mission ? Vous vous fixez un objectif dès le départ ? Ou c'est un peu flou à la fin ? Comment tu sais qu'une mission est terminée d'ailleurs ?

Yoan Thirion

Ça, c'est une super question.

Alors, je suis pas très bon là-dedans. Un truc que je n'arrive pas bien à faire, c'est dire non. Ce qui fait que des fois ça me cause des soucis parce que je fais des choses, je me perçois comme très enthousiaste et j'ai envie de toucher à tout. Ce qui fait que j'ai une incapacité à dire non parce que tout m'excite entre guillemets. Ce qui fait que des fois, je n'arrive pas à poser les limites du mandat. Le mandat, il ne fait que de s'étendre.

C'est ça que je mets le petit préambule, c'est que, ouais, mais on aurait bien aussi peut-être qu'on voit ces trucs-là. Puis moi, ouais, ouais, c'est vrai que ça l'air cool. Donc je continue à gratter. Donc là-dessus, je ne pas très bon, je l'avoue.

Après, manière générale, si je veux faire un truc, si je veux sur une mission bornée dans le temps, ce que je fais, c'est qu'à intervalles réguliers, le modèle d'auto-évaluation qui est utilisé avec l'équipe au moment du kick-off, l'objectif c'est de faire en sorte qu'il y ait de l'amélioration dessus, donc qu'il ai de l'amélioration perçue par l'équipe. ça c'est un premier point. On peut se fixer un premier milestone à se dire, à dans deux mois, on rejoue ce qui a été fait au kick-off et on veut y voir de l'amélioration.

Ce que j'aime bien faire aussi c'est voir, prendre du feedback de manière anonyme sur le programme qui est déroulé. Je fais un sondage avec les équipes que j'accompagne, histoire de prendre le pouls et de voir s'ils ont envie qu'on continue ensemble ou pas, s'ils perçoivent de la valeur dans ce que je leur délivre ou pas. Donc ça, c'est assez factuel. Même si c'est sur l'ordre du ressenti, c'est démontrable facilement à du management.

C'est la première chose. Et on peut se dire qu'on arrête au bout de 2-3 mois, parce qu'il a déjà eu de la valeur produite, et l'équipe ne pas forcément de valeur à continuer. Ça peut être une première option.

Souvent ce que j'aime bien mettre en place en termes de métrique, c'est une métrique toute bête, c'est de se dire "c'est quoi l'évolution des stocks". L'évolution des stocks, c'est on est une équipe, on délivre de la valeur, on peut appeler ça des items de backlog, des user story, des features, des tâches, peu importe. Et on va mesurer l'évolution de ce stock-là, notre capacité à délivrer dans le temps et à faire évoluer les stocks, à répéter nos efforts et à délivrer un maximum de valeur.

On va mesurer l'évolution du stock de bugs. C'est-à-dire le nombre de bugs qui sont à traiter par l'équipe.

Et puis, il y a un autre truc que j'aime bien évaluer et suivre en termes de stock, c'est l'évolution du stock de dette technique. Donc matérialiser quelque part, c'est souvent un truc que je fais aussi au démarrage, c'est de demander, "de votre perception, c'est quoi votre dette" ? Et on va essayer de la loguer.

Et donc ce qu'on va essayer de faire, c'est de faire diminuer ce stock de dette, histoire d'influencer positivement l'évolution du stock de ticket. Souvent, en fait, on voit que quand on commence un accompagnement, on a un stock de dette qui est assez important.

Alexandre

Ouais.

Yoan Thirion

Et puis on a un stock de features, avec une capacité de délivrer de la fonctionnalité qui est assez bas parce qu'on est un peu englué dans du code legacy, et on n'a pas la confiance pour itérer sur le code. Une fois qu'on commence à avoir cette confiance-là, que le stock de dette commence à baisser, on voit une évolution du nombre de fonctionnalités qu'on a en capacité de délivrer. Ça on peut le mesurer - et c'est en réalité assez simple à mettre en place.

Donc ça, ça peut être un objectif de se dire : dans trois mois, on essaie de diminuer, de pouvoir visualiser ça.

Après, je mets toujours un énorme warning là-dessus. C'est qu'il peut y avoir, mais il n'y a pas de lien de causalité direct entre l'intervention d'un coach dans une équipe et l'évolution de ce stock. On peut avoir un effet bénéfique qui fait que le stock de dette diminue, aider l'équipe à augmenter leur vélocité. En revanche, s'il n'y a pas d'inflexion ou s'il n'y a rien qui change, ce n'est pas forcément de la responsabilité du coach. Ce n'est uniquement la venue du coach qui va influencer positivement ces métriques-là. Mais ce n'est pas non plus la venue du coach qui va influencer négativement.

Il a quelque chose autour de la métrique en plus de ça, c'est que quand on commence à être orienté métrique, on va essayer de tout faire pour l'obtenir - quitte à truquer la métrique.

Alexandre

Oui, il y a ce risque là en plus. C'est plus un faisceau d'indicateur.

Yoan Thirion

C'est ça. C'est la loi de Goodhart. Lorsqu'une métrique commence à devenir un objectif, elle n'est plus une bonne mesure.

Alexandre

Il faut combien temps pour commencer à ressentir des résultats ?

Yoan Thirion

C'est là où il peut y une très bonne perception au niveau équipe et pas d'impact sur les métriques. L'impact sur les métriques peut être plus long.

C'est là où c'est compliqué de piloter par la métrique. Si on est dans un contexte où les gens font confiance à leurs employés, font confiance à leur N-1, leur N-2, etc, en fait, on peut tous se fixer sur le ressenti de l'équipe.

Si elle a le sentiment de fournir de la valeur, on sait qu'à un moment donné ça va être payant. Il y aura un mieux sur la qualité de ce qui va être délivré et il y aura une augmentation de la vélocité de l'équipe à terme.

Ce que j'aime bien observer, c'est à trois mois. Et des fois, on n'a pas forcément des résultats. Des fois c'est plus long. Des fois ça met six mois, un an, ça dépend des accompagnements.

Et là aussi, je vais revenir sur l'histoire de l'accompagnant, du coach, qui n'est pas forcément responsable de tout. Je suis déjà allé dans des équipes où il n'y avait qu'une seule ou deux personnes sur 7-8 qui étaient moteurs et qui avaient envie de faire en sorte que ça change. Les cinq autres, si tu n'arrives pas à les embarquer, est-ce que c'est vraiment de la faute du coach ? Le collectif, si tu n'arrives pas l'embarquer, c'est compliqué.

Mais ça, en général, j'en parle en amont. S'il a 7 personnes, mais que je n'arrive à en embarquer que 2 qui ont envie d'amener du changement, qui ont envie de revoir leur manière de faire, de tenter vers un mieux. çà, c'est des choses que je discute surtout avec le sponsor et on acte les choses. On voit s'il a moyen de faire changer l'état d'esprit, s'il a une volonté majeure et forte, ou changer les personnes en cas de dernier recours, ou bien me changer moi, c'est peut-être moi qui ne fit pas et dans ce cas, je quitte le contexte.

Alexandre

Ok. Parce que qui est-ce qu'il t'appelle ? C'est un développeur qui te sponsorise dans l'équipe ? C'est le CTO qui fait appel à toi ?

Yoan Thirion

Souvent, c'est les CEO ou juste en dessous. Ils veulent démarrer une démarche qu'on peut appeler démarche craft, démarche d'amélioration des pratiques de dev, d'amélioration de qualité. C'est souvent ce genre de profil. À de rares occasions, c'est l'Enterprise Architecture, la cellule d'architecture qui m'appelle.

Alexandre

Ok.

Yoan Thirion

Ils ont envie de changer la manière dont sont conçues les choses et ils ont envie d'avoir un relais aussi l'architecture et les gens plus sur le terrain. Souvent, il a une décorrélation et ils cherchent de l'accompagnement pour rapprocher les deux mondes : le monde de l'architecture, le monde du dev, et de réussir à créer de la cohésion.

Alexandre

Et tu les trouves comment tes clients aujourd'hui ? Est-ce que c'est eux qui viennent à toi ? Est-ce que tu démarches un peu des entreprises ?

Yoan Thirion

Il y a des deux. Si je prends les clients purement craft, la manière dont je les ai eus, c'est plus le bouche-à-oreille quand j'étais sur le marché luxembourgeois. Après, aussi via les connexions. A un moment donné, j'ai dû sortir en urgence d'un client. J'ai retrouvé tout de suite parce que j'ai un réseau qui est plutôt pas mal. Et du coup, l'entraide dans mon réseau qui me permet de trouver facilement des missions.

Là, depuis que je suis arrivé en Suisse, c'est plus le réseau de l'entreprise. On a une bonne aura ici avec Pyxis, ce qui fait qu'on n'a pas de mal à se trouver des missions. Je profite de l'image de Pyxis pour être bien occupé on va dire. Mais sinon, c'était plutôt le bouche-à-oreille. J'avais une bonne réputation sur marché du Luxembourgeois. Et le fait d'avoir le Meetup Craft par exemple aussi, c'est un moyen qui m'a permis de tisser des relations et d'avoir un réseau qui a augmenté, qui m'a permis aussi au moment où ça allait peut-être moins bien de retrouver des clients rapidement.

Alexandre

Qu'est-ce qui t'a motivé à lancer le meetup Software Craftsmanship Luxembourg ?

Yoan Thirion

Toujours la même motivation et je ne sais pas trop d'où elle vient. Il faudrait que je la creuse avec un psy, mais ce besoin de partager. Il y vraiment quelque chose autour de ça. Quand je mets "sharing is caring" sur mes posts, sur mes partages, c'est que j'y crois réellement. Il a une citation que j'aime bien, c'est que "la connaissance est la seule chose qui grandit quand on la partage" et ça raisonne chez moi.

Chaque fois que je découvre quelque chose, je me dis, c'est trop cool, c'est super intéressant. Moi, si ça m'apporte de la valeur, je me dis, il faut que les autres le découvre. Si je vois que personne ne connaît, que je trouve ça super important, que je trouve que ça peut nous améliorer notre quotidien, je me dis qu'il faut que je le pousse, il faut que je réussisse à le transmettre. Je veux le partager. Et je vois comment ça résonne chez les autres. Il a vraiment cette volonté de partager.

Et dans le partage, moi, j'y trouve aussi quelque chose d'assez individualiste. Quand je partage, je grandis aussi. Et il y a vraiment cette soif de grandir aussi en moi.

Quand tu partages, tu es obligé de connaître un peu mieux le sujet, tu es obligé de creuser la chose. Donc il y a ce côté-là aussi. Je grandis en le faisant. Et puis en partageant, j'adore, pouvoir rebondir avec quelqu'un, avoir des avis contraires. Je trouve ça excellent. J'ai le sentiment de contribuer à quelque chose et de grandir en partageant. Donc l'idée du Software Crafter, c'était ça.

Au départ, de faire ça en présentiel. Malheureusement, on s'est fait disrupter par le Covid. Mais au départ, l'objectif était de réussir à monter une communauté de pratique, faire des codings de jeu ensemble, etc. Avec le Covid, ça a shifté en ligne. Et on a eu des super speakers. Les speakers, j'avais beau avoir vu leur talk avant, je voulais que les gens s'y intéressent aussi.

Une personne comme Adam Tornhill, tu regardes une de ses conférences, je trouve que ça change la donne. Des gars comme Sandro Mancuso. Quand j'ai lu son bouquin il y a plus de 10 ans maintenant, pour moi ça a été une révolution. J'ai l'impression que le gars, il était dans ma tête, il avait verbalisé des trucs que je ressentais dans le monde du dev. C'est des personnes qui m'ont inspiré. Et si ça peut inspirer d'autres personnes tant mieux.

Alexandre

Et comment est-ce que tu les as trouvés tes invités ? Tu les as contactés comme ça ?

Yoan Thirion

Ouais, en mode stalking. J'étais un stalker. J'allais suivre leur parcours.

Des personnes comme Sandro, c'était assez simple. Il y en a d'autres où c'était plus compliqué. Mais souvent les gens répondent quand on les contacte en direct sur Twitter, LinkedIn ou quoi. ça m'a surpris.

Et je ne me mets pas de limites. J'ai peut-être ça aussi, C'est un truc. Je me dis, au pire, je me prends un non. Au pire la personne ne me répond pas. Donc ce pas grave.

J'utilisais beaucoup LinkedIn, Twitter et compagnie pour essayer de choper des intervenants.

Et puis en conférence aussi. J'allais les voir et je leur disais « je suis le host du Software Crafter Lux, est-ce que ça te dirait de venir faire ce talk-là dans notre meet-up ? Et ça a plutôt bien marché pour le coup. Oser aller voir les gens. Même si je ne suis pas super bon en anglais. Je n'ai jamais eu la barrière de la langue. Je ne me suis jamais mis une barrière psychologique à ne pas aller voir les gens.

Alexandre

Ok.

...

Yoan Thirion

Je m'en suis toujours sorti.

On a réussi à faire venir en physique Mark Seemann au Luxembourg d'ailleurs à l'époque. On a eu des beaux noms et de supers interactions. On a eu vraiment des belles personnes.

Alexandre

Ok.

Yoan Thirion

Voilà, je recommande à ceux qui ont envie de se lancer, n'hésitez pas. Franchement, il a pas pire que ne rien faire. Le pire qui arrive, c'est un non.

Alexandre

Et du coup, la communauté physique a pris quand même ? C'était plus une communauté en ligne finalement.

Yoan Thirion

Avec le Covid, ça n'a pas pris du tout et on est resté en ligne par la suite. Là, ça fait quasiment 3 ans que je suis parti. J'ai donné le bébé à Guillaume qui s'en occupe avec Arthur et Tinaelle.

Alexandre

Après, tu aq une autre expérience de communauté en ligne qui est Advent of Crafts. Est-ce que vous prévoyez une édition pour 2026 ?

Yoan Thirion

Ce n'est pas encore acté.

L'idée d'Advent of Craft, pour ceux qui écoutent, c'est de réussir, comme tu disais tout à l'heure, à créer une communauté autour du calendrier de l'Avent. On a conscience qu'il le calendrier de l'Avent du code qui est vraiment trop bien, mais il est très branché algorithmique et compétition. Nous, on a la volonté de créer une communauté de pratiques autour du craft, donc de l'artisanat logiciel, de faire découvrir des pratiques de dev qui nous paraissent utiles, intéressantes, importantes au quotidien - de manière ludique et en privilégiant l'entraide.

Notre mantra pour l'année dernière, c'était :

Build BETTER code, TOGETHER, every day

L'idée était de dire, tous les jours, on découvre un challenge de code ensemble et on s'aide de la communauté pour grandir, on se donne du feedback, etc.

Ce qu'on a envie de promouvoir, c'est ces échanges-là qui peuvent avoir énormément de valeur.

C'est d'ailleurs ce qui été mis en avant dans les retours sur l'édition 2024, c'est qu'il a eu plein de ping-pong. Y'avait des gens qui se posaient des questions, ils profitaient des réponses des autres ou bien des regards différents, on en débattait. "Qu'est-ce que tu penses de ça", "Moi, je l'ai implémenté comme ça, comment je pourrais faire différemment", ou bien, "qu'est-ce que vous en pensez". C'est grandir ensemble.

On a cette notion de "pas du tout de compétition". Au contraire, c'est comment on fait pour s'entraider, grandir, découvrir de nouvelles choses, partager des points de vue qui peuvent être différents, voir des fois opposés. Et c'est totalement OK, on a envie d'avoir de cultiver cette différence.

D'ailleurs, on a cultivé la différence aussi sur les langages de programmation. Chaque jour, durant le mois de décembre, il y avait un code Kata qui était publié, un petit challenge de code. On essaie d'être le plus inclusif possible : PHP, C-Sharp, Kotlin, Java, TypeScript et compagnie. Il y en avait normalement pour tous les goûts.

Chaque jour, un kata. Et le lendemain, une proposition de solution. Avec des explications étape par étape de comment nous, on l'a résolu.

L'année dernière ça m'a demandé énormément d'investissement tout au long de l'année.

Je ne me voyais pas remettre cet investissement-là durant cette année. Du coup, à minima, je parle en mon nom, moi, je ne vais pas recommencer. J'ai eu plein d'autres impératifs cette année, plein d'autres choses qui vont changer à la fois sur la vie perso et pro. Je ne pourrai pas m'engager autant pour la communauté.

Tout repose sur les épaules de Yann. Et c'est quelque chose à clarifier avec lui car je ne veux pas m'engager pour lui.

C'était une super aventure. Pour l'année 2024, on a mis la barre vraiment très haute. S'il a une édition 2025, je pourrais contribuer sur une ou deux journées, mais je ne pourrais pas avoir le même niveau d'engagement.

Si ça doit se faire, j'invite la communauté qui nous écoute à se manifester. L'année dernière, on avait cinq contributeurs. Donc n'hésitez pas, Yann pourrait coordonner ça et puis aider à créer des katas / des challenges d'une manière encore plus collaborative.

Alexandre

Ok, donc si on peut vous aider, c'est de proposer des challenges.

Yoan Thirion

Ouais carrément. Et là-dessus on a plein d'idées en fait. J'ai un listing quasi infini pour l'Advent of Craft. L'année dernière, il fallait choisir pour 25 journées, mais il a plein de trucs qu'on a mis sur le côté. Il y avait des choses autour du TDD Guided by Zombies, du Smoke testing, trouver un bug avec git bisect, identifier des hotspots. Et puis on a vraiment envie de pousser aussi des concepts Green IT.

Alexandre

Oui.

Yoan Thirion

Potentiellement numérique responsable avec de l'accessibilité, des choses au niveau de l'amélioration de performance, etc. On a un milliard d'idées. Donc là-dessus, tout le monde est bienvenue et peut contribuer.

Alexandre

Ce backlog est-ce qu'il est public ?

Yoan Thirion

Je ne crois pas, non. C'est un Trello qui est quelque part. Je pourrais peut-être le rendre public. Je ne pas si on a encore les droits de rendre public un Trello. Puisqu'ils ont changé le mode de licence. Je pourrais regarder en tout cas. Si ça intéresse des gens.

Alexandre

Ok

J'ai participé à la première édition. Et c'était hyper sympa de voir les solutions des autres, de recevoir du feedback sur tes solutions. ça c'était cool.

Et sur la dernière édition il y avait plus de monde. C'était en anglais. J'ai l'impression que c'était principalement français la communauté. Ou est-ce que vous avez touché une communauté plus large au niveau de l'Europe ?

Yoan Thirion

Ouais c'était plutôt Europe. On avait des Allemands pour sûr - on reconnaît bien l'accent comme nous les Français quand on parle anglais. Puisqu'on a fait des sessions aussi live en fait. Il a Alexandre qui avait lancé ça donc c'est trop cool de voir aussi. Y'a un autre Alexandre qui avait proposé des sessions live tous les jours. Il découvrait le challenge du jour.

Alexandre

Ok.

Yoan Thirion

Et puis il invitait d'autres personnes à le rejoindre. Des personnes se connectaient, tout monde était bienvenu, et du coup il y a eu pas mal d'échanges. Il a des moments où on le faisait en français et d'autres en anglais quand il y avait dans la communauté des non francophones. On a touché quand même pas mal de nationalités différentes. Il y avait un participant d'Afrique du Sud. Et des États-Unis puisqu'on avait touché la communauté d'Atlanta et de Montréal. Dans les personnes récurrentes cette année, il y en a eu une quinzaine qui postaient quasiment tous les jours.

Alexandre

OK.

Oui même en tant que participant, c'est prenant.

Yoan Thirion

Ouais, c'est clair.

Alexandre

Est-ce que tu as des cas d'usage IA/LLM préférés ?

Yoan Thirion

J'ai eu un truc la semaine dernière. J'étais en atelier, en mode programming, et on se posait la question de comment on pourrait traduire un test property-based qui est exprimée en C-sharp, à quoi il ressemblerait en Kotlin, avec une librairie qui s'appelle Kotest. J'ai laissé mouliner dans GPT et en deux secondes, j'avais le résultat pour montrer un peu les différences de langage. Donc ça, trouve ça cool pour faire de la migration juste rapide, et de voir conceptuellement, à quoi ça pourrait ressembler.

Après, je suis en train de préparer une conférence avec Alexandre Trigueros, qui aura lieu dans deux semaines, et c'est justement la thématique. C'est, comment on utilise les GEN.AI dans un contexte Brownfield, donc avec du code Legacy.

Là, les cas d'usage, que je trouve intéressants et qui ressortent de ce que j'ai pu expérimenter en le promptant bien avec Claude Code, c'est la compréhension d'une base de code assez rapide. Tu lui fais expliciter c'est quoi les features qui sont implémentées. Là-dessus, c'est plutôt intéressant en fait, ça bouffe énormément de ressources par contre - financières et environnementales.

Je lui ai demandé de décrire l'architecture. Alors, si on lui demande juste ça, forcément ça va être très light. Par contre, je lui ai dit que ce que je voudrais comprendre, c'est de manière très précise, qu'il me crée un diagramme 4C au format Mermaid. Et donc je voulais 4 niveaux du format 4C : contexte, containers, components, jusqu'à classe. J'avoue que c'était assez bluffant de le voir faire ça.

ça permet d'avoir une bonne overview de ce qui se passe au niveau du système.

Ensuite, je lui ai dit : maintenant que j'ai cette compréhension-là, je voudrais voir sur une des fonctionnalités particulière comment elle est implémentée, du front-end jusqu'au back Fais-moi un diagramme de séquence assez complet de ce que tu peux déterminer. Et là-dessus, sur de la compréhension, il est plutôt malin.

On n'est pas sur d'analyses fines de code, n'est pas sur du refacto de code, donc il n'a pas besoin d'avoir une compréhension fine du langage ou de la compilation ou de quoi que ce soit. Et là, je trouvais que c'était assez intéressant ce qu'il arrivait à faire.

En revanche, les use case sur lesquelles je ne fais pas du tout confiance, c'est sur du refacto, et quand il faut faire du code. J'ai eu le sentiment de perdre du temps dans tous les essais que je fais.

J'ai d'ailleurs désactivé l'auto-completion avec Copilot parce qu'en fait, il me génère du code et souvent, c'est pas forcément ce que je veux, ce qui fait que je perds plus de temps à comprendre ce qu'il m'a pondu qu'à l'écrire moi. Il y a ça.

Et pour écrire des tests, c'est une catastrophe. Le use case que souvent les gens amènent, c'est "moi j'aimerais bien que l'IA m'aide à générer des tests sur mon code".

Je suis plutôt adepte du Test Driven Development - donc écrire mes tests en premier. Là, on est sur un brown field. Il n'y a pas de tests, où les tests ne pas très bien écrits. Qu'est-ce qui se passe si je le prompt et je lui dis exactement ce que je voudrais voir en termes de structure de test, ce que je voudrais qu'il teste en termes de niveau, etc. Et en réalité, le résultat que j'ai réussi à obtenir, n'était pas fou. Il était même d'être fou.

Et en plus de ça, il ne compilait pas. Il n'a pas la notion de compilation. Pour lui, ne traite que des tokens. Le résultat que j'avais, c'était une coquille qui me permettait d'itérer. Ce que je vois en termes d'usage, il faut vraiment se limiter à la micro-fonctionnalité et bien le prompter pour être en capacité de faire quelque chose d'assez précis, avec assez de contexte pour qu'il soit assez malin pour nous apporter de la valeur. Sinon, personnellement, je trouve qu'il m'apporte moins de valeur que si je faisais des choses à la main.

Hier, j'ai testé un autre use case. Je lui dit : je voudrais ajouter une nouvelle fonctionnalité. Tu commences depuis le contrôleur, tu commences en mode TDD outse-in, tu m'écris un premier test d'intégration. Ensuite, tu vas faire ça, tu vas faire ça, tu vas faire ça. L'architecture, doit ressembler à ça. Je voudrais qu'il ait ça comme ça, etc. J'ai essayé d'être vraiment ultra précis sur ce que je souhaitais. Et je lui dit, avant que tu commences, tu me fais un graphe Mikado. Donc tu vas mettre tout ce que tu prévois de faire.

Il m'a pondu quelque chose qui était assez clean pour le coup. Et puis derrière, quand il a commencé à fonctionner, ça n'avait rien à voir. Il a commencé direct en changeant des entités métiers. Je lui dit : non, commence par un test d'intégration. Il n'a pas suivi ces instructions là.

On en parlait hier avec Alexandre. On a eu le sentiment d'être avec un stagiaire qui ne maîtrise pas ce qu'il fait. Tu lui donnes des instructions. Il va te pondre quelque chose. Mais derrière, il n'est pas en maîtrise de ce qu'il fait. Il faut tout le temps être derrière.

Des fois, le temps passé, à être derrière est plus chronophage que le temps à faire toi-même.

Alexandre

Le Mikado c'était un truc que tu pouvais utiliser ? ou même pas ?

Yoan Thirion

Ouais peut-être. C'est ce que je me suis dit. En fait, il a fait une première version qui était plutôt cool, pas trop compliquée etc. Et je lui dit, "pour moi il manque des choses là". Je lui dit, "il manque ça, rajoute les moi". Et là, il est parti en vrille complètement. Il m'a rajouté la notion de Unity of Work. Je ne lui avais absolument pas parlé de ça. Il me dit, "ouais t'as raison". Puis il me dit, "je vais t'introduire de l'Event Sourcing". Mais pourquoi en fait ? Je ne te l'ai pas demandé.

Et voilà. Lui, il est probabiliste. J'ai utilisé le mot "clean architecture". Comme sûrement plein de gens qui associent clean architecture et even sourcing. Ce qui fait que lui a été aussi loin que ça, à faire de l'event sourcing sans maîtriser. Pareil avec des choses qui étaient complètement ésotériques et qui n'avaient aucun sens. Il passait l'injection de dépenses, il instanciait des choses à la main. Après pour aller récupérer une instance de repository, il fallait passer en dur. Tout le monde recevait les Units of Work. Il fallait faire Units of Work.le-nom-du-répository.safe de mon objet, etc. Il avait créé de la dépendance de partout. Et je lui avais dit de demander de le faire sur un segment à part dans le code, de créer des nouveaux projets et compagnie. Vraiment, l'image du stagiaire.

Là je crache dessus, mais il n'y a pas que du négatif.

Pour moi, l'analyse de code. C'est assez bluffant ce que j'ai réussi à sortir en quelques promptes, analyse d'un nouveau projet Brownfield, enfin d'un projet Brownfield.

Et puis l'autre usage que je vois qui est intéressant, c'est pour faire un POC. Franchement pour tester une idée, c'est bluffant.

La dernière fois, j'étais dans le meet-up Goat Review. Il y avait Pierre qui prenait la parole, qet qui disait, "moi j'ai codé une extension rapidement avec Claude".

Je me suis lancé. Je me suis dis, ok, je vais tester aussi de mon côté.

Pendant qu'il parlait, en 10 minutes, en le promptant, je lui ai dit, je vais définir les deux stories que je voulais qu'il supporte dans une extension Chrome. J'ai mis des critères d'acceptation, etc. Puis je lui dit, maintenant amuse-toi avec ça. Et il m'a fait un POC. J'appelle ça un POC parce que ce n'était pas du tout viable en production, mais il m'a fait un POC d'extension qui était plutôt intéressant, avec une bonne coquille, une représentation visuelle qui était intéressante.

C'était un truc pour analyser une page web en gros. C'était une petite extension Green IT et je lui ai dit que j'aimerais bien savoir des choses supplémentaires. Les requêtes, vont dans quelle zone géographique, si tu arrives à identifier les choses comme ça, c'est quoi l'impact de la page, etc. Il m'a fait des onglets, etc. L'extension était plutôt cool en termes de design. Elle pourrait prouver une idée rapidement. C'est intéressant.

Alexandre

Ok.

C'est cool. On recommande souvent de commencer avec un prototype jetable. Ça te permet de voir où vas la complexité, quels vont être les concepts, et de gagner du temps par la suite.

Yoan Thirion

Carrément ouais.

Et en termes d'UI/UX, moi je ne suis pas un expert CSS donc il est meilleur que moi pour le coup. Pour tout ce qui mise en page etc, tout ce qui est présentation, il m'a fait gagner un temps de dingue. C'est sûr que si j'avais voulu le coder, ça m'aurait pris beaucoup plus de temps. 10 minutes c'est rien. Et c'était un cout de 50 centimes, pour une extension codée en 10 minutes avec Claude.

Mais dedans, le code en termes de maintenabilité, c'était un gros fichier JS avec le café, le thé et compagnie et des choses qui sont hard codées un peu partout. Mais pour un POC c'est bien. Tu le mets dans les mains des utilisateurs, tu vois comment ils réagissent, tu t'itères dessus avec un outil, et ensuite tu peux lancer le développement quand tu vois qu'il a de la valeur à le faire.

Alexandre

Mmh. Ok. C'est l'atelier Jurassic Code ?

Yoan Thirion

Oui. Dans ce talk là que je vais faire, il n'y aura pas le côté extension. Mais pour le reste le code est en ligne et on est en train d'itérer dessus. Il y a une application avec un back en .NET, un front en React.

Alexandre

Vous le partagez où ?

Yoan Thirion

Alors ce sera à DevOps Days à Genève.

Alexandre

Ok.

Je pourrais peut-être attendre un peu qu'ils soient en ligne. Ou peut être qu'il ne sera pas en ligne tout de suite.

Yoan Thirion

Il ne pas en ligne du tout, c'est un atelier. Par contre, toutes nos ressources seront en ligne. On a un board miro et on a créé des cartes pour l'atelier. On va distribuer des cartes aux participants pour qu'ils aient un use case à expérimenter avec leur GEN AI préférée. Du genre, essayer d'analyser l'architecture de la solution.

Alexandre

Ok.

Yoan Thirion

Chaque petit groupe va avoir une mission et puis derrière, on fera des briefs de ce qu'ils ont pu découvrir, et de nous les observations qu'on a pu faire, avec Claude pour moi et GitHub Copilot pour Alexandre. Toutes les ressources seront en ligne sur Miro et sur GitHub.

Alexandre

Est-ce qu'il y a des trucs que tu refuses de faire avec l'IA ?

Yoan Thirion

Ouais, beaucoup de choses en fait. J'essaie de l'utiliser le moins possible pour des questions environnementales. Il a plein de choses que je me refuse de faire.

En fait, il a un truc qui m'avait marqué. A la sortie de GPT, j'avais commencé à faire des posts avec. J'ai voulu écrire un post sur Astérix. C'était l'Iris blanc qui venait de sortir. J'avais adoré la BD parce que ça parle de coaching. Il y a un côté très satirique autour du monde du coaching qui m'a parlé bien. Je trouvais qu'il avait plein d'enseignements et de second degré qui étaient intéressants. Je voulais partager ça. J'ai commencé à prompter GPT et il m'a dit : "moi je ne pas l'iris blanc. Ma connaissance d'Astérix se limite à je ne sais plus quoi".

Et là je me suis dit, tant pis, je n'écris pas mon poste.

J'essaie de m'observer, je prends du recul et je me dis. Mais en fait ton intention c'était quoi ? C'était de partager. Tu as vraiment envie de le partager. Qu'est-ce qui t'empêche de le faire ? Juste parce qu'un outil n'est pas présent, tu ne sais plus rien faire ?

A ce moment-là, j'ai eu une prise de conscience. Je me suis rendu compte que je devenais dépendant. Du coup, il a plein de choses où je me force à ne pas l'utiliser. Typiquement, écrire un poste, écrire un article. Pour ça j'évite de l'utiliser. C'est du plagier à l'échelle en réalité, c'est une copie de ce que les autres ont fait. Je préfère que ça garde un petit peu plus de sens, plus ancré dans ce que moi j'écris.

Alors j'écris pas très bien malheureusement. Je ne travaille pas assez ma plume, mais au moins c'est moi derrière.

Alexandre

Ça vient avec la pratique.

Yoan Thirion

Ouais, c'est ça, exactement.

Alexandre

C'est qui les 3 devs t'inspirent le plus en ce moment ?

Yoan Thirion

Ouf, en ce moment...

Je ne suis pas trop fanboy.

En ce moment, c'était aussi vrai il y a plus longtemps. Il y a vraiment Sandro Mancuso qui m'inspire beaucoup. C'est quelqu'un d'une humilité incroyable et qui est ultra intéressant. J'avais eu la chance d'ailleurs de le faire revenir à l'époque, de passer du temps avec lui sur Luxembourg. Donc je dirais Sandro Mancuso.

Après, il a des personnes que j'apprécie beaucoup dans les communautés craft ou agile française, qui ne sont peut-être pas ultra connus, mais en tout cas que j'apprécie vraiment. Là, j'ai envie de citer Philippe Bourgau. Je ne collabore pas forcément avec lui, mais à chaque fois qu'on a des interactions, pareil, je détecte la même humilité, la même envie de partager qu'avec des personnes comme Sandro. Et ça, c'est des choses que j'apprécie énormément. On voit que la personne, elle te donne tout. Elle est dans le partage, elle veut faire grandir l'autre, etc.

J'adore ces gens qui sont dans cet état d'esprit.

Après, il y en a plein que j'apprécie. Un dev qui a potentiellement changé ma manière de concevoir du code, qui est peu connu, enfin un dev, ou architecte, je sais pas comment on l'appelle, mais c'est Scott Scott Wlaschin avec son bouquin Domain Modelling Made Functional. Vraiment excellent bouquin. Et pareil, je me suis pris du temps avec lui. Pendant le Covid, je me suis payé sa formation et donc j'étais deux jours avec lui. Pareil, un énorme passionné qui est énormément orienté partage. Moi, quand il y a un match entre ce qu'il véhicule et ce qu'ils sont, j'adore.

Alexandre

Cool.

Scott, c'est une petite star dans le milieu fonctionnel, j'ai l'impression.

Yoan Thirion

Oui. Et ses talks sont excellents.

Alexandre

J'en ai regardé un sur Railway Oriented Programming. C'était tellement simple et limpide

Yoan Thirion

C'est clair.

Et sa formation, je crois qu'il la donne encore. Il l'a fait toujours avec avanscoperta d'ailleurs, en Italie. Je pense qu'il l'a fait encore en ligne, et sa formation est vraiment top. C'est en F-sharp. ça peut en rebuter certains. Mais le but n'est pas de devenir expert du langage ou d'être expert avant de venir. C'est vraiment de voir ce que ça peut apporter d'écrire du code de cette manière-là. Je me souviens de comment il interview un domaine expert et comment en même temps il arrive à prendre des notes et à faire du pseudocode qu'il va en fait retranscrire en deux secondes en F-Sharp. C'était assez hallucinant. Ils se mettent d'accord sur des règles business en live avec un expert du métier etc. Franchement c'était bluffant. Excellente expérience avec lui.

Alexandre

Et tu arrives à en retirer des choses, toi qui fait principalement de l'orienté objet ?

Yoan Thirion

Ouai. Comme je disais, le côté fonctionnel, je le trouve intéressant et utile aussi, surtout avec des principes comme fonctionnal core, impératif shell. L'idée d'avoir un corps très orienté, fonctionnel, pur, histoire d'avoir des choses qui sont prédictives, facilement testables, etc. et du shell autour. Tout ce que tu peux apprendre dans le bouquin, c'est ultra utile pour essayer de concevoir un functional core.

Au quotidien au boulot, je fais de moins en moins de dev quand même, je ne vais pas le cacher. Quand on fait de l'accompagnement, on est un peu moins dans le dev pur, mais ça m'aide beaucoup en termes de réflexion. Je considère que toutes ces pratiques, tous ces principes, c'est des grilles de lecture supplémentaires et des ouvertures qui t'apportent une meilleure compréhension de tout ce que tu peux faire et de tout ce que tu peux ne pas faire aussi. Je trouve ça intéressant, de pouvoir faire des choix en conscience. C'est d'ouvrir des portes et se dire à ce moment-là, ça va peut-être le coup d'utiliser ça - ouais mais là non, etc.

ça m'apporte dans tous les cas à augmenter ma capacité à percevoir. Avoir des perceptions différentes du monde ça va être toujours aidant au quotidien en fait.

Alexandre

Ok.

Je crois qu'on a bien balayé. Est-ce que tu as un mot pour la fin ?

Yoan Thirion

J'aime bien finir par une recommandation de bouquin. J'en lis beaucoup. Et il en un qui m'a marqué il y a pas longtemps. Alors, on va dire que je suis chiant avec lui, c'est Anti-K.O. de Mathieu Dardaillon. C'est comment il l'a appelé ça ? Le principe et outil visuel, le livre boussole pour reprendre la main sur votre avenir.

En gros, c'est un bouquin qui va recenser beaucoup de pratique. Je prends une page au hasard. Celui-là par exemple, c'est un outil de se dire "c'est quoi ma journée minimum viable". C'est de se poser la question de qu'est-ce que je dois à minima faire en termes d'activité pour considérer que ma journée avait de la valeur.

Et je trouve ça trop bien. Il y a plein de choses comme ça, d'exercices pour essayer de du sens au quotidien. On est noyé par des news qui sont potentiellement négatives, anxiogènes. Et je trouve que ce genre de bouquins, ils sont réellement intéressants pour ça. Il y a plein de trucs que je connaissais, mais dans tous les cas, je les recommande largement.

Et il a des trucs trop cool aussi. Je me suis dit si je fais un bouquin, faut absolument que je fasse ça aussi. Des fiches détachabes à la fin du livre. Explorer ta terrain incognita. Tu détaches et tu l'accroches dans ton bureau par exemple.

Je ne les ai pas faits pour l'instant puisque je compte les mettre à l'école, mais il y a plein de trucs super intéressants en terme d'outillage. Comment naviguer à travers ce monde qui peut être perçu comme ultra démoralisant. Comment on arrive à aller de l'avant et se questionner. Il y a plein de petites activités intéressantes.

Alexandre

C'est quoi ta journée minimale viable ?

Yoan Thirion

Il faut que je prenne beaucoup l'air. Malheureusement, elles sont souvent pas viables ces derniers temps. Et y'a un truc autour de lecture. ça j'y arrive plutôt bien.

Tous les jours c'est de lire quoi. Lire, découvrir quelque chose. C'est pour ça que j'ai toujours deux bouquins en parallèle en lecture, un à la maison et un dans mon sac à dos. Comme ça je ne me pose pas de questions.

Alexandre

Ok.

D'ailleurs, voulais te demander. Tu as partagé des notes assez détaillées sur Fundamentals of Software Architecture. Est-ce que c'est un livre que tu recommandes ?

Yoan Thirion

Ouais, je vois que tu parles. J'ai pas été jusqu'au bout sur la prise de notes. Je voulais en faire une infographie de livre. Mais c'est beaucoup trop toufu. Ouais, je le recommande carrément.

Tout le début, je le trouvais ultra intéressant. Et un truc qui m'avait marqué, c'est arrêtons de parler de "NFR" de "non-fonctionnal-requirements" dans nos produits. ça laisse à penser que ce ne sont pas essentielles, qu'on peut mettre sur le côté. Mais ce n'est pas le cas des aspects sécuritaires par exemple, ni des aspects de scalabilité. quand on les traite qu'à la fin, potentiellement, on avoir de gros problèmes.

Eux, parlent d'un truc, c'est, les caractéristiques d'architecture, les matérialiser. Ils viennent avec un modèle et des guidances assez complètes sur ça peut être quoi de l'architecture, l'architecture d'entreprise ou pas d'ailleurs, et comment on rapproche le rôle de dev et d'architecte.

Il y a vraiment plein de trucs super intéressants. Moi je recommande de le mettre dans les mains surtout des personnes qui se voient comme un rôle détaché des équipes, que sont souvent les architectes. Malheureusement en entreprise, ils sont souvent décorrélés du quotidien des équipes. Dedans, il y a plein de choses autour de comment on cultive cette relation, comment on garde le pied dans les équipes pour être en capacité de comprendre que les choix qu'on peut faire au niveau architecture, ils impactent les gens et vérifier que c'est bien implémenté.

Mais pour vérifier, fait, n'est pas juste vérifier, c'est aider les gens à mettre en œuvre. Et donc, on met en œuvre avec eux. La vérification, c'est facile, mais comment on met en œuvre, comment on s'entraide ? Et y a vraiment cette culture avec les devs qui est intéressante. Et puis derrière, y a toutes les pratiques et principes d'architecture qui peuvent être mis en place en entreprise. Bon là, ça rejoint un peu les trucs autour des enterprises, architectures patterns, etc., qui sont d'autres livres intéressants par ailleurs, mais que je n'ai pas forcément mis en avant dans les notes du livre que j'ai pu prendre.

Et pareil en termes de structure, il y avait un truc que je trouvais intéressant, c'est à la fin du livre il y avait un questionnaire pour chaque chapitre avec des questions clés. C'est justement ça qu'on retrouve dans mes notes, les questions clés. Je trouve que c'est intéressant d'avoir ce petit compte rendu à la fin du livre qui maximise ton apprentissage.

Alexandre

Qui t'aide à réfléchir à ce que tu viens de lire.

Yoan Thirion

Exactement, tu as un petit reflect à la fin, et tu peux poser avec tes propres mots ce que toi tu en as compris.

Alexandre

Je vois que j'ai complètement zappé la partie sur Coda. On peut en parler un peu ?

Est-ce que tu as une idée du programme déjà ?

Yoan Thirion

On peut ouais.

Oui, j'ai une bonne idée du programme.

Coda, c'est une école d'informatique qu'on monte à Dijon. C'est le deuxième campus. Orléans a été monté il y a 3 ans. Pour nous, ce sera la première rentrée en septembre. C'est une école sup-informatique. On ouvre avec une classe de 1ère et 3ème année pour un bachelor full-stack dev.

Le programme est assez clair. On reprend quasiment intégralement ce qui marche déjà à Orléans, pour cette première année en tout cas, tel quel. Et donc il y aura beaucoup. On commence avec de l'algorithmique, du bas niveau, pour enchaîner vers des langages plus haut niveau : du PHP et ce genre de choses. Et puis surtout voir la programmation orientée objet dès la première année.

Alexandre

OK.

Yoan Thirion

La particularité qu'on a chez Coda, c'est qu'on veut se démarquer des autres écoles.

On dispense de la pédagogie en mode sprint, c'est-à-dire qu'on ne pas avoir des étudiants qui vont commencer la journée avec deux heures d'anglais, puis deux heures de bas niveau, puis trois heures de tir à l'arc, j'en sais rien.

On va avoir des séquences bien bornées, d'une journée à trois semaines, sur des sujets spécifiques. Histoire d'être en mode focus et de maximiser l'apprentissage.

Dans ces intervalles de temps, on va privilégier la pratique. Par le projet ou des activités autour de la découverte de ces compétences-là.

Mon rôle là-dedans : je suis référent en pédagogie. Je travaille à la fois, comme son nom l'indique, sur la pédagogie. ça veut dire quoi ? Ça veut dire créer le programme, les maquettes pédagogiques, les objectifs pédagogiques qui en découlent. Et recruter les intervenants, faire le suivi des intervenants, construire leurs interventions avec eux, vérifier que tout va bien, etc. C'est ce volet plutôt pédagogique côté intervenants. Le volet pédagogique côté étudiants, chez Coda, on fait intervenir des professionnels qui seront là manière ponctuelle, va dire, ils n'ont pas vocation à rester toute l'année, qui viennent par exemple, tu pourrais venir faire trois semaines de Java par exemple, d'orienter objet.

Donc, tu viens pour trois semaines - et donc moi mon travail c'est de t'onboarder, t'aider à construire le programme, les activités, etc. Et derrière, c'est à moi de m'assurer du coup parce qu'il n'y que des intervenants ponctuels, de m'assurer que les étudiants ont tout ce qu'il faut pour être en capacité de réussir. Et c'est de les aider, de les mentorer s'il a de l'incompréhension, s'il a des besoins d'aller plus profondément sur un sujet ou autre. C'est vraiment de l'accompagnement ici, d'étudiants dans leur quotidien.

C'est quelque chose que je n'ai pas l'habitude de faire parce que je suis plutôt dans le monde de l'entreprise. Donc ça me sort de ma zone de confort entre guillemets et je vais voir ce ça donne à la rentrée.

Alexandre

Ok. Ça a l'air génial.

Yoan Thirion

Oui. Et bien évidemment, vu mon background, mon optique aussi, c'est d'amener du craft à l'école. Donc amener de l'artisanat logiciel et les pratiques qui vont avec. Dès la deuxième année, je pense. La première année, il y a besoin de poser des bases en termes d'algorithmiques, en termes de programmation.

Alexandre

Ok. Et là, tu vas faire ça à temps plein ou en plus de tes coachings ?

Yoan Thirion

En ce moment, c'est en plus de mes interventions chez les clients. C'est deux jours semaine sur Coda et trois jours chez mes clients. Et à la rentrée, au mois de septembre, c'est du plein temps référent pédagogique.

Alexandre

Ok, nouvelle aventure du coup. Donc là, tu déménages en même temps.

Yoan Thirion

C'est pour ça que l'année-ci, l'Advent of Craft, ce n'est pas ma priorité - dans ce sens où j'achète un appartement, je refais des travaux, je change de boulot, il faut monter le programme. Il y a beaucoup d'inconnues pour moi. Je ne connais pas vraiment le monde de l'enseignement donc, je n'en rajoute pas.

Et une chose importante que je n'ai pas dit. Chez CODA - s'il a des étudiants qui l'écoutent ou des intervenants qui voudraient venir - on a vraiment une touche aussi très particulière.

Alors, on a vocation à s'implanter dans des territoires très petits. L'objectif, c'est d'être dans des villes de moyenne importance, ou Dijon. Enfin, de moyenne importance en termes de population. Donc une ville comme Dijon, par exemple, ici. Histoire de s'implanter dans un terroir très local, le plus proche des entreprises, faire de l'alternance, et dans des milieux qui sont potentiellement dépourvus.

Et on a aussi la volonté d'amener le Green IT dès la première année. Notre optique, c'est de former des gens et agrémenter les notions de Green IT et de numérique responsable tout au long de la scolarité. De travailler à la fois sur les compétences techniques, mais aussi d'ouvrir à c'est quoi l'impact du numérique, et comment nous on peut être acteurs, enfin comment individuellement chaque étudiant peut être acteur d'une transition ou tout cas d'un monde meilleur dans les années à venir.

C'est ça qui me fait envie et on est une bonne équipe. On est une super équipe même sur Dijon et Orléans.

Alexandre

Trop bien.

Est-ce que t'as un deuxième mot de la fin ?

Yoan Thirion

Aha.

Un deuxième mot de la fin.

Oui, je peux conseiller cette BD-là : Au-dedans.

On en a pas parlé, mais Au-dedans, je la trouve intéressante. Ça se lit vite et visuellement c'est chouette. C'est sur la puissance des relations. Je n'ai pas envie de spoiler, donc je vais pas en dire plus, mais si vous avez l'occasion de lire au-dedans, je vous invite à la lire.

Alexandre

Oui.

Yoan Thirion

Et ça fait écho à un autre livre que je trouve super intéressant : The Good Life.

Je pourrais partager l'infographie que j'ai faite de ce livre aussi. Le livre qui est tiré de la plus grande étude sur le bonheur au monde, qui a été réalisé par Harvard sur 80 ans. Ils ont étudié sur 80 ans qu'est-ce qui fait le bonheur au quotidien des gens. Et ils ont croisé avec d'autres études qui sont faites à travers la planète, donc c'est super intéressant. L'étude d'Harvard se concentrait sur les États-Unis. Elle était fortement biaisée par le mode de vie américain, donc ils se sont intéressés aussi aux études sur les autres continents. Il y a la rigueur scientifique, plein de conclusions qui sont ultra intéressantes, sur ce qui fait notre bonheur, et ce qui fait qu'on est heureux au quotidien / ou pas d'ailleurs.

Alexandre

C'est dans ce livre-là qu'ils parlent des Blue Zones ?

Yoan Thirion

Non.

Alexandre

Non ? Ok, c'est le nom du haut d'un reportage alors.

Yoan Thirion

Blue Zone, me fait penser à Leadership is Language avec Blue Zone, Red Zone. Je ne sais pas si ça te parle.

Alexandre

Les Blue Zone, pour moi, c'est des zones dans le monde où tu as des communautés de gens qui ont une meilleure longévité qu'ailleurs. Quand on regarde c'est quoi les facteurs, à priori, ça a l'air d'être lié à un tissu social qui est bien construit.

Yoan Thirion

C'est vrai qu'il y a cet aspect-là dans le livre. Ce n'est pas forcément là où ils mettent le plus de focus. Mais oui ça en fait partie. Clairement. Les conclusions, c'est, je vais spoiler, mais c'est le pouvoir des relations, le fait d'avoir des relations saines et de se sentir épaulé, soutenu au quotidien, aimé, de prendre soin de ces relations-là, des relations qui nous épanouissent - qui fait qu'on a une meilleure longévité pour le coup et qu'on est plus heureux au quotidien. Il y a un impact sur la longévité des relations.

Et pareil, ils déconstruisent des mythes que je trouve intéressants. Est-ce que l'argent fait le bonheur ? Je vous laisse découvrir c'est quoi leur réponse. Je pense qu'on a tous une grille de lecture là-dessus et je trouve ça super intéressant. Plein de mythes qui sont déconstruits.

Alexandre

Ok.

Yoan Thirion

Au-dedans, Good Life, pour moi, pouvez y aller les yeux fermés.

Alexandre

Génial. On peut se quitter là-dessus du coup.

Merci beaucoup pour ton temps et ta disponibilité.

C'était cool de t'avoir et d'échanger avec toi.

Yoan Thirion

Merci Alexandre, merci pour l'invitation.

Alexandre

Avec plaisir.