Bienvenue sur le podcast Artisan Developer, l'émission pour les programmeurs qui veulent
vivre une carrière épanouissante.
Prêts à passer au niveau supérieur ? C'est parti !
Aujourd'hui je suis avec Lisa Fassi, Lisa bonjour.
Bonjour.
Est-ce que tu peux te présenter en quelques mots pour ceux qui ne te connaissent pas ?
Oui bonjour, c'est Lisa Fassi, je suis développeuse jusqu'à l'autre depuis maintenant deux
ans donc développeuse full stack.
Et le sujet du jour que tu m'as proposé et que j'aime beaucoup, ça tourne autour
du scallop de comment tu passes d'une toute petite équipe à une grosse équipe.
Est-ce que tu peux nous raconter déjà un petit peu ton histoire et après pour rentrer
dans le fond du sujet autour des leçons que tu en retires des paternes que tu as pu
voir et des trucs que tu as trouvé cool et moins cool ?
Oui, bien sûr.
Du coup pour ce qui est de mon histoire, j'ai eu l'occasion de travailler dans beaucoup
de petites start-ups où on était maximum 2 ou 3 dans toute l'entreprise au global.
Donc le but c'était de sortir à reproduire rapidement et de pas forcément faire attention
à la qualité de code.
Et là depuis peu, ça va faire deux ans, j'ai eu l'opportunité de travailler dans
une nouvelle boîte, Scalo, qui est une entreprise qui elle scale totalement que ce soit du côté
humain ou technique.
Donc maintenant je suis dans une équipe de 30 à 40 développeurs et notre objectif
est de passer d'un gros monolithe à des microservices et vraiment séparer les responsabilités.
Pourquoi vous voulez faire ça ?
On veut faire ça parce que la gestion d'un monolithe c'est pas vraiment simple.
Et si par exemple on a une erreur quelque part dans la plateforme, tout va s'éteindre
alors que le fait d'avoir des microservices fait qu'on peut éteindre une partie de la
plateforme et ça ne posera pas forcément problème sur le client.
Il ne s'en rendra pas compte, ça permet d'avoir une meilleure gestion.
Alors ton sangon point me paraît tout à fait valable.
Le premier me paraît quand même assez fallacieux.
C'est-à-dire ?
Parce que si tu crois que tu vas y gagner d'un point de vue simplicité de maintenance
en passant d'un monolithe à du microservice, là je pense que c'est un peu une erreur
d'appréciation pour la faire.
C'est vrai totalement, je me suis peut-être mal exprimé.
Ce n'est pas forcément de la simplicité de maintenance, mais disons que c'est plus
simple quand tu cherches la raison du problème.
Tu sais exactement où aller, tout est vraiment compartimenté, une responsabilité.
C'est vraiment l'expérience que j'en ai.
C'est intéressant parce que la petite expérience que j'en ai quand tu commences à avoir des
systèmes explosés, tu as des nouveaux challenges qui apparaissent au niveau en termes de lenteur
système, en termes d'appels qui peuvent maintenant échouer, qui ne pouvaient pas échouer avant,
et surtout de traceabilité de ta pile d'appels.
Quand tu résous ces enjeux-là sur du micro, comment vous l'avez fait pour résoudre ces
problèmes-là ?
De justement la question de la traceabilité, c'est souvent quelque chose qu'on se pose
dès le début quand on veut mettre en place un nouveau microservice.
Parce qu'on part d'un monolithe.
Du coup, on a déjà une solution définie et fonctionnelle, et le but c'est de la découper
en petite partie.
Du coup, au moment du découpage, on sait qu'on a des traces actuellement, et c'est des traces
qu'on utilise, donc on veut les garder.
Du coup, on va essayer de monter une architecture et faire en sorte que si quelque chose plante,
on a toujours une trace pour savoir pourquoi il a planté, avec quel paramètre et qu'est-ce
qui s'est passé ? Juste avant.
Du coup, par exemple, si on a actuellement lâché ce qu'il y a, on utilise le ruby pour
le bonolithe encore.
Bientôt, il faut arriver.
Mais donc, par exemple, tu peux avoir une gestion de tes jobs et savoir quand est-ce
qu'il a été envoyé.
Donc tu sais que ton job s'occupait à écrire dans une queue.
Donc une fois que tu es dans la queue, tu sais à quelle heure est-elle arrivé le message,
quel paramètre est-il ?
Et puis après, tu as la trace de ce message dans la queue.
Donc tu sais quand est-ce qu'il a été envoyé.
Ensuite, quand tu récupères dans ton microservice, tu as encore une trace de la donnée.
Oui.
Et du coup, tu arrives à remonter une pile d'appel de manière assez fluide et facile.
Oui.
Oui, oui.
Honnêtement, c'est quelque chose de qui aide en plus au quotidien.
Quand tu as un bug ou un souci sur la plateforme, ça aide vraiment de pouvoir savoir à quel
moment, qu'est-ce qui s'est passé.
Ok, c'est cool.
Et du coup, tu as eu l'occasion de travailler avec des microservices.
Alors peu, c'est ce que je te dis.
Moi, je peux les quelques fois où j'ai commencé.
Moi, j'ai une image assez négative de ce pattern-là.
Parce que je l'ai trop souvent vu mal employé.
Je l'ai beaucoup plus vu mal employé que bien employé.
Et quelques fois où j'en ai eu besoin de moi, on était allés très progressivement.
Et ça en commençant par un monolithe et en commençant à le découper.
Et là, ça s'est plutôt bien passé.
Mais parce qu'on amenait juste ce dont on avait besoin, est-ce qu'on était capable de gérer?
J'ai vu des projets où, sans mentir sur un truc où on a été marré en prod,
un nouveau directeur technique arrive.
Et je crois qu'il y avait, il passe dans monolithe à, je ne sais pas,
s'il n'y avait pas une centaine de microservices.
Je ne blague pas.
Et on était facilement en sûr en dizaine.
Il y avait au moins 20 ou 30 microservices,
dont peut-être deux qui étaient rédits pour la prod.
Donc, quand tu arrivais en tant que développeur là-dedans,
tu te retrouvais à devoir lancer 12 machines Docker.
Enfin, c'était du grand n'importe quoi pour une équipe de trois personnes.
Ah oui, d'accord.
Tu vois, c'est ce genre de choses que j'ai vu.
J'ai vu des trucs dans des grosses boîtes du CAC 40.
Les mecs, ils se sont fait plaisir.
Ils ont démarré, ils ont zéro utilisateur.
Ils ne savent pas où la charge utilisateur va aller,
mais ils ont eu une microservice.
Oui, je trouve que ça recoupe avec le sujet de,
tu commences à me tout mettre en place,
alors que tu n'as même pas encore validé l'importance de ton projet.
C'est que je trouve que les microservices,
c'est intéressant à partir du moment où ton produit,
il est validé, utilisé par des utilisateurs.
Et tu as des problèmes de performance,
tu as des problèmes de gestion de erreur.
Et du coup, là, les microservices deviennent intéressantes
parce que tu vas pouvoir isoler tes actions.
Mais si tu mets que des microservices dès le début,
la complexité est là dès le début et ça ne change pas en fait.
Je pense que ça ne change pas grand-chose.
Ah, je pense que c'est juste pire.
Ouais, c'est même pire, oui.
Et vous, les microservices, quand vous avez commencé
à migrer sur ce pattern-là,
vous étiez à combien ?
Ça, c'est une question intéressante.
Vous l'avez fait quand vous étiez encore tout petit
ou vous l'avez fait une fois que vous étiez étoffé en termes de ressources ?
Ah non, on l'a fait, on a commencé,
on devait être une quinzaine, je pense, dix-quince.
On n'avait pas forcément de connaissances dans AWS à ce moment-là
parce qu'on s'est lancé sur AWS, du coup.
Et du coup, ça a permis de...
Enfin, on a vraiment fait petit à petit un microservice
par un microservice et au fur et à mesure,
le but était de partager la connaissance,
faire les documentations qu'il fallait
et commencer à avoir une sorte de schéma
sur comment tu fais pour démarrer un microservice.
Comme ça, à la fin, tout le monde est un peu courant.
Et quand tu arrives aujourd'hui, on doit avoir quelque chose comme...
je dirais, six microservices en prod qui tournent et qui fonctionnent.
Donc quand tu arrives en tant que nouveau développeur,
normalement déjà, tu n'es pas censé avoir besoin de tout installer,
c'est censé fonctionner direct.
Et après, quand tu arrives, quand tu as besoin de travailler sur un microservice,
tu as forcément la documentation qui va avec
et tu as forcément l'équipe qui a travaillé dessus,
qui est prête à avoir avec toi pendant une heure,
tu ne bordais tu et t'expliquer comment ça fonctionne
et l'architecture du microservice.
Oui, donc vous êtes mangé à la complexité d'une archimicroservice
progressivement et vous avez grandi en compétences et en...
oui, en skills et en organisation autour de ça.
Exactement, exactement.
Ce qui me paraît être la meilleure pour pas dire la seule manière intelligente
de faire ça, c'est cool.
Et d'ailleurs, si toi, auditeur, tu as d'autres expériences positives
de comment passer au microservice,
tu peux me contacter et on fera un épisode
pour démonter ce que je viens de dire et ça me fera plaisir.
Et alors toi, comment tu as vécu ce passage de...
Quand tu es rentré chez Skilloo, vous étiez combien et aujourd'hui, vous êtes combien ?
Alors, en global, quand je suis rentré chez Skilloo,
on était, on va dire, 80.
Et là, maintenant, on est 225.
OK. Et chez les techs, au dev, il y avait combien de personnes ?
Et au niveau de dev, quand je suis arrivé, on devait être 15
et maintenant, on est une grosse trentaine.
OK. Donc tu as vécu en gros foie de quoi ?
Exactement.
Et puis franchement, c'était très intéressant
parce que quand je suis arrivé, c'était les devs qui s'occupaient un peu de tout.
Et on n'avait pas vraiment d'équipe d'architecture,
on n'avait pas d'équipe qui s'occupait de l'infra et de la data.
Et du coup, j'ai vu ça se créer.
En fait, quand tu vas créer des microservices,
tu vas avoir besoin de connaissances,
qu'un développeur n'a pas forcément.
Et le développeur, pour moi,
c'est pas son rôle de mettre en place une architecture et tout ça.
Lui, il va pouvoir la développer, il va pouvoir réfléchir à la technologie et tout.
Mais il n'est pas censé aussi réfléchir à avoir l'architecture la plus optimisée
et en plus, gérer l'après si il y a des problèmes d'infra ou des choses comme ça.
Du coup, c'était intéressant de voir comment l'équipe a évolué
pour que les développeurs puissent avoir un rôle de développeur
et qu'on ait une vraie équipe infra qui s'occupera de tout ce qu'il y a,
l'infrastructure, les impasses d'architecture et tout.
Création, si je puis ça.
Et tout l'équipe d'attaque s'occupe de la partie donnée.
Et le développeur s'occupe que de son métier.
Ah, c'est drôle.
Ça peut être que... Alors, c'est vraiment extrêmement drôle.
Parce que juste avant, j'ai enregistré un podcast avec quelqu'un
où on parlait du métier de DevOps et où je défendais cette thèse,
donc je n'ai aucune idée de l'ordre de publication des épisodes.
Mais on n'est frontalement pas d'accord, en fait.
Pour moi, le développeur doit s'intéresser à tous ces enjeux qui sont autour,
qui ne sont certes pas d'écrire du code.
Mais si ça n'intéresse pas aux enjeux d'infra, d'admine,
je trouve que ça fait partie du métier, quand en fait.
Non, oui. Par contre, là, je te rejoins.
Là-dessus, je te rejoins totalement.
T'es censé t'y intéresser et t'es censé être au courant de ce qui se passe.
T'es censé connaître.
Nous, par exemple, tu as toujours un développeur qui va faire partie
de la décision quand il faut créer l'architecture.
Et il va toujours être au courant de comment agirer sa donnée,
comment agirer l'architecture et tout ça.
Et il va être décisionnaire dans tout ça.
Mais c'est juste que c'est pas totalement sa responsabilité à lui de tout faire.
Sinon, il ne peut pas tout faire à 100 % moi, je trouve.
Sinon, tu perds énormément de temps et d'efficacité, je pense.
C'est pas une personne de le faire, c'est une équipe.
Oui, mais quand tu fais dans une équipe,
tu finis toujours par avoir chaque personne qui aura un rôle spécifique à la fin.
Donc, ça finit par se séparer en différentes tâches.
Qu'est-ce t'en penses ?
Non, je ne partage pas à 100 % ce que tu dis.
Qui est des gens qui se spécialisent ou qui se musclent plus sur certaines parties.
Oui, ça se sent pari naturel et ça va dépendre un peu des affinités.
Maintenant, pour moi, c'est vraiment l'équipe qui est responsable.
Tu vois, en tant qu'XP, exprime programmeur de la première heure,
on ne se posait pas toutes ces questions.
Il y avait une plateforme, il y avait un produit, on était responsable de la prod.
Oui, j'ai essayé de connaître la session il n'y a pas longtemps avec d'autres développeurs,
justement, où cette évolution du métier de développeurs, c'est dit,
d' dernières années, où à l'époque, le développeur faisait vraiment tout.
Quand tu le dis comme ça, j'ai l'impression d'être vieux.
C'était pas le but.
Oui, dans le temps, il paraît que ça se passait comme ça.
Non, mais par exemple, moi, je viens de une école.
Attends, ne bouge pas, je reviens ce métin.
Non, mais par exemple, moi, je viens de une école où il y a beaucoup de développeurs qui pensent comme ça.
Moi, je l'ai beaucoup pensé comme ça pendant longtemps aussi.
Pour moi, si tu fais un projet, toutes les parties du projet sont ta responsabilité,
t'es le développeur, t'es censé penser à la bonne architecture avant de commencer à travailler.
Ensuite, quand tu commences à travailler, tout va bien.
Et tout ce qui est gestion de l'infrastructure, de tes outils, où est-ce que tu vas host ça,
comment tu vas faire pour ça et ça.
Avant, tout était la responsabilité du développeur.
Sauf que, du coup, tu avais pas mal de failles dans le sens où, même si c'est une équipe,
admettons, on va pas dire un développeur, c'est une équipe entière,
tu as pas mal de failles où si par exemple, la personne n'a pas toutes les connaissances côté Afra,
il y a des choses qu'il va pas pouvoir faire comme il faut,
où elle va devoir y térer au moins 30 fois sur la même chose avant de finir par avoir quelque chose de qualité.
Et pour moi, c'est pour ça que le rôle de développeur a évolué.
Et donc, le fait de se spécialiser, le fait de se spécialiser vraiment permet d'être bon dans ces sujets-là.
Exactement. Et c'est pour ça que, après, pour moi, ça rejoint un peu le débat quand on dit un développeur seigneur.
C'est un développeur seigneur dans un langage spécifique,
parce qu'il s'est spécialisé dans ce langage.
Bon, c'est un peu pareil.
Et encore un sujet où on n'est pas d'accord.
Ah, c'est fou, hein !
Wow ! Est-ce que c'est un conflit générationnel, les Y contre les X ?
Ou les Z, parce que moi, je suis plutôt un Y.
Tiens, n'ai en cas l'année, toi.
Oula, je sais pas si j'ai envie de le dire. Je suis né en 97.
Tu es né en 97, l'année où je passais mon bac.
Ok.
Donc, quand mon premier enfant est né, tu rentres en OCP.
Ok.
Wow ! Ah oui, j'avoue que vu comme ça, c'est...

Après, je trouve ça très intéressant, justement, de comparer toutes ces nouvelles mentalités, si je puis dire,
et la mentalité de base, en fait, de comment c'était censé fonctionner.
Parce que c'est vrai que...
Attends, bouge pas, je remasse encore deux-trois dents, là.
Qui nous s'est fait de toi ?
Ah mon Dieu ! Mais qu'est-ce que je prends cher dans cet épisode ?
Et maintenant, je vais m'attraire en filtre.
C'est moins de 30 ans, tu ne viens pas sur le podcast, il n'y a pas moyen, quoi.
Non, mais c'est hyper intéressant.
C'est... Alors, est-ce que c'est générationnel ?
Tiens, auditeurs qui m'écoutent, si tu te retrouves dans une des deux catégories,
est-ce que tu penses que c'est générationnel ? Tu m'envoies un petit mail,
benoîtarobasartisandeveloppeur.fr.
Mais non, c'est hyper intéressant, dans cette vision du métier.
Tiens, raison, en fait, quand je m'écoute parler, je me disais,
« Ouais, dans le temps, faisais comme ça ! »
Mais finalement, peut-être que c'est moins que le vieux crouton qui voit pas que ça bouge, en fait.
Non, après, moi, je pense qu'un développeur, il est censé savoir tout faire.
Dans le principe, il est censé savoir tout faire.
C'est juste que je pense que c'est plus simple de gérer une problématique
que de devoir passer à tous les aspects de ton projet.
Après, par contre, il doit être au courant du tout.
Bah, tu vois, l'accès inverse que j'ai déjà vu qui m'a un peu perturbé,
je vais reprendre le même exemple que j'ai donné dans l'autre podcast, justement.
J'ai ce souvenir, une fois, d'un développeur qui galérait sur un sujet réseau,
et quand on a prononcé le mot « DNS », je l'ai vu ouvrir des grands urans,
il me disait « C'est quoi un DNS ? »
Et là, je me suis dit « Mh, merde, il y a un problème ».
Et là, je me suis dit « Il y a eu un trou dans la raquette de la formation,
qu'est-ce qui se passe ? ».
Pourtant, le gars, il avait reçu une formation plutôt long sur type école linge ou un truc comme ça.
Et je me dis « Où est-ce qu'il y a un problème ? »
Il a expérimenté, il a reçu une formation qui se veut complète,
et il ne sait pas ce qu'il y a un DNS.
C'est moi qui suis un vieux con là où il y a un problème quelque part.
Je comprends. C'est vrai que c'est assez perturbant.
Non, par contre, moi, je pense un peu comme toi.
Je trouve qu'il y a des bases à avoir en tant que développeur quand même.
T'es censé savoir comment fonctionne ta machine, comment fonctionne le réseau.
Et de base, il faut que tu trouverais comment y interpréter le code que tu développes,
et ça t'aide à comprendre beaucoup de choses, sur pourquoi ça ne marche pas,
pourquoi ça réagit comme ça.
Non, je suis assez étonné qu'il ne connaisse pas un DNS non plus.
C'est beaucoup.
Ok, ça va. Tu es gentil, tu fais un effort.
Tu rejoint un peu ma cause alors.
Non, je me pense vraiment.
En plus, c'est intéressant parce que le discours que tu tiens,
c'est sur la spécialisation et la capacité à aller en profondeur sur certains sujets.
C'est exactement celui que je tiens.
Et sur d'autres aspects, notamment dans le blockchain,
j'ai fait le choix de me spécialiser sur une tranche très étroite
qui est le développement de smart contracts sur machines virtuelles et terrames.
Et là, si tu n'as rien compris à ce que je t'ai dit, c'est normal.
Mais en gros, c'est le code qui tourne sur les blockchain,
parce que les blockchain permettent d'exécuter du code de manière décentralisée.
Et c'est tout l'intérêt de la chose d'ailleurs.
Et donc, ces contrats-là ont des spécificités très particulières qui font que
il y a des gros enjeux de sécurité.
Il y a plein de sujets autour de tout ça.
Et le parti pris que j'ai eu, ça a été de dire
c'est très spécifique, ça demande un niveau d'expertise très profond, assez étroit et profond.
Et du coup, je ne vais plus faire plein d'autres choses, notamment du Web 2.
Je n'ai plus en faire, je ne peux plus faire de développement Web pour me focusser là-dessus.
Donc tu vois que moi aussi, je rejoins ta manière de voir le truc.
Et effectivement, quand tu arrives à une trentaine,
il peut y avoir un rationnel économique et de performance,
à dire il y en a quelques-uns qui vont se spécialiser sur tel domaine
et qui vont devenir un peu les garants du truc.
Oui, c'est ça, il faut bien des experts en fait.
Et sauf que pour être un expert dans un domaine,
tu es obligé de laisser de côté quelques domaines.
Après, je ne dis pas que tu peux toujours y revenir plus tard,
mais pour être expert dans un seul domaine, au moins un,
il faut que tu t'y consacres à 100% pendant un certain temps.
Du coup, tu ne peux pas, dans une vie,
tu n'as pas le temps de voir tout ce qui se passe dans le domaine du développeur en fait
et d'être un expert dans tout, je veux dire.
Dans le temps, on pouvait ma petite.
C'est vrai, c'est vrai, ou je vais les dire quelque chose, mais...
Ils ont fait ma fille, ils se sont complexifiées, voilà.
Non, papy, t'as pris ta médicament ?
Hey merde, moi je voulais faire ce métier jusqu'à la fin de mes jours,
tu crois que je ne vais pas pouvoir en fait ?
Si, je pense que c'est faisable, mais c'est juste qu'il faudra faire des choix,
on peut pas tout apprendre.
Il n'y a pas le temps de tout apprendre de manière à être un expert dans le domaine.
Mais alors, du coup, ça se passait comment quand tu étais dans les petites boîtes ?
Ah non, les petites boîtes, c'était très intéressant parce que...
Parce qu'elles n'ont pas vraiment les moyens de ça, tu vois,
tu n'as pas les moyens de te payer des experts en général quand tu es petit.
C'est ça, et surtout qu'il faut qu'ils sortent un produit rapidement et qu'ils fonctionnent
et eux, ils n'ont pas forcément...
En fait, je vais reposer un article que j'ai vu sur ton site il y a pas longtemps
où c'était quelqu'un qui disait sur LinkedIn un post LinkedIn qui disait
que le Tévi-dévé au début en sort four, le Dédévé au début en sort four,

Si tu me dis que tu es du côté de Kevin, on va commencer à se fâcher.
Je ne suis absolument pas de ce côté-là.
Mais en tout cas, c'est comme ça que ça se passe malheureusement.
Je ne suis pas pour parce qu'en fait, c'est horrible pour après
parce que de toute façon, il faudra tout refaire.
Donc pour moi, c'est une perte de temps phénoménale.
Mais le problème, c'est que c'est ce qui se passe clairement
quand tu démarres un projet dans un startup.
C'est que la personne qui t'a engagé, elle te demande pas de faire du code propre
et de qualité ou quoi, elle te demande de sortir un produit fini à telle date.
Il faut que ça fonctionne, il faut que les utilisateurs soient contents
et eux, ils se rendent compte que la qualité de code est importante,
qu'à partir du moment, ils commencent à avoir beaucoup d'utilisateurs
et que la solution, elle est bancale en fait
et ça tient plus. Il commence à y avoir plein de edge-case,
il commence à y avoir trop de gens, donc des lenteurs.
Et c'est là qu'on se rend compte que de faire tout vite dès le début,
c'est la pire des idées en fait. C'est vraiment la pire des idées.
C'est une perte de temps phénoménale après en fait.
Mais c'est comme ça que ça se passait dans les startups dans lesquels j'étais.
C'était clairement ça, ils ne demandaient pas, il n'y avait pas de code au début
ou il n'y avait rien. Il faut que ça marche comme ça, sur ce site, ça fonctionne.
Donc fait le fonctionner sur mon site. En gros, c'était ça.
Quel leçon tu tires, je te propose que ce soit le mot de la fin de notre échange.
Quel leçon tu tires de ce passage de 15 à 30 days,
ou en tout cas de cette accélération que tu as pu voir dans les différents projets
entre quand tu es passé de 3 à 15 à 30 ?
Je dirais qu'il faut savoir prendre le temps.
Il faut savoir aller vite, mais tout en prenant le temps quand même au début.
Disons que la préparation de l'architecture et la mise en place
de tous les outils au début, c'est ce qui va définir que tu auras moins de difficultés après
et que ce sera moins long après.
C'est clairement ce que j'en ai retenu.
Ne pas hésiter à prendre le temps et la communication et le partage des connaissances
c'est super important entre les équipes et les personnes.
Qu'est-ce que tu as vu qui était le plus efficace là-dessus ?
Parce que ça c'est un vrai sujet qui est mal...
Au niveau du partage de connaissance ?
Oui, que je trouve rarement bien géré.
Je trouve que c'est un vrai sujet dans pas mal de boîtes.
C'est très compliqué, c'est un petit peu un sujet sur nous je trouve aussi.
On a réussi à payer quelque chose en faisant d'office, une documentation par exemple.
Si tu développes un nouveau microservice ou que tu travailles sur quelque chose de nouveau,
tu vas obligatoirement faire la documentation qu'il va avec.
Il faut souvent par exemple faire lire cette documentation à quelqu'un qui n'a pas travaillé dessus
pour voir qu'est-ce qu'elle comprend.
Et en dehors de la documentation, il faut aussi beaucoup communiquer dessus.
On fait pas mal de présentations sur le travail qu'on fait,
du coup tous les deux semaines, on présente le travail qu'on a fait les deux dernières semaines en équipe.
Mais à l'ensemble de la boîte ?
À l'ensemble de l'équipe ?
À l'ensemble des développeurs, oui.
C'est cool ça.
Et c'est souvent à ce moment-là qu'on s'occupe d'expliquer en fait.
Ça marche comment, on a fait comme ça.
Après sinon, on fait des workshops aussi.
On fait pas mal de workshops.
Dès qu'on voit que tu as fait un microservice un peu compliqué,
on va de suite faire un workshop d'une demi-heure, 3,5 heures,
avec tous les techs pour leur expliquer c'est quoi l'architecture du projet, comment ça marche,
et qu'est-ce qu'on a utilisé.
Comme ça tout le monde est toujours au courant.
Très cool.
Bravo pour tout ça.
Merci Lisa d'être venue aujourd'hui.
Si les auditeurs veulent te suivre et en savoir plus sur ce que tu fais, ils viennent où ?
Sur LinkedIn, au nom de Lisa Fassi.
C'est tu.
Écoute c'est parfait.
Merci Lisa.
Avec grand plaisir, merci à toi.
Quant à toi cher auditeur.
Si tu as envie de suivre ce qui se passe avec Kevin,
je t'invite à venir sur le blog artisandeveloppère.fr.
J'y raconte tout ça.
C'est le feuilleton 2023.
Allez tcho.