Bienvenue sur le podcast Artisan Developer, l'émission pour les programmeurs qui veulent
vivre une carrière épanouissante.
Prêt à passer au niveau supérieur ? C'est parti !
Aujourd'hui, je suis avec Nicolas Bonavent, Nicolas bonjour.
Bonjour Benoît.
Est-ce que tu peux te présenter en quelques mots pour ceux qui ne te connaîtraient pas ?
Je m'appelle Nicolas Bonavent, je vais travailler chez Software médical depuis 15 ans maintenant
et je suis Head of UX et j'ai le plaisir d'être aussi le manager d'une équipe pluridisciplinaire
de designer, ce qui est plutôt mon métier, et d'une équipe de développeur front pour
une équipe design systems.
Et le dev c'est un petit peu mon métier.
Bien voilà qui pose bien le contexte, alors on pourrait croire que ça va être encore
un épisode sur l'UI et l'UEX, mais non.
L'idée cette fois c'est de parler du binommage puisque j'ai publié un article qui a l'air
d'avoir bien plu à la communauté et tu avais réagi là dessus d'ailleurs en disant
que pour toi en tant que manager c'était quelque chose d'important le père programming.
Et du coup j'étais vraiment tric de comprendre un petit peu ta manière de réfléchir ça.
Qu'est ce que tu vois d'ailleurs ce père programming et comment tu le mets en œuvre
aux synthès équipes ?
Je crois que le encourager ce genre de pratique ça tire une pelote assez longue et la question
on va dire à la base de tout ça c'est le questionnement sur la santé du produit et
les bonnes pratiques qui vont encourager la santé du produit.
Et le père programming ça répond à plein de critères là-dedans et moi le premier qui
je me dis en tête c'est la circulation de la connaissance quand on a deux développeurs
comme c'est le cas donc le produit c'est un design system donc c'est un produit au
service du produit qui est utilisé par 200 personnes on diront chez software.
Un design system on peut rappeler deux secondes ce que c'est c'est un... est ce que tu peux
le dire avec des mots comme ça ? Alors un design system en fait c'est un ensemble
d'actifs, de codes, d'actifs, de prototypes, des librairies de codes, des librairies de
prototypage qui vont quelque part structurer créer un langage commun de conception fonctionnelle
et technique.
Alors nous on appelle ça un produit au service du produit qui vont quelque part la facilité
que ce soit la conception fonctionnelle pour les designers ou l'intégration de compte
pour les équipes qui vont le conserver.
Le plus connu c'est le matériel.
Donc notre design system il est utilisé donc à peu près 200 personnes et il y a deux
En fait s'il n'y a pas de circulation de la connaissance, c'est à dire que chaque
DF porte 50% et quand l'un part en vacances, c'est à dire qu'on ne peut pas bosser sur
le compte pour son autre ou quand il y a une personne qui... si il y a une personne qui
quitte à la société, ça veut dire que... enfin il y a 50% du code qui devient du code
non-nutrisé et c'est extrêmement dangereux dans le cas de la pérennité de la position.
Donc le premier élément pour moi c'est favoriser la circulation de la connaissance.
Le deuxième élément par ricochet c'est on va dire l'émulation et le challenge.
Au delà du père c'est important de favoriser les bonnes pratiques.
TVD par exemple, voilà enfin du code propre et quelque part partagez ce qu'on est en train
d'écrire avec son copilote pour réutiliser la métaphore que vous utilisez.
Je crois que c'est extrêmement vertueux, ça permet de créer un dialogue, une envie
de s'améliorer et de faire toujours mieux.
Et le troisième point principal je dirais qu'il y a aussi le côté proximité et bonne
entente.
Je ne sais pas si c'est une conséquence ou un pré-requis.
C'est peut-être un peu des deux.
Je pense qu'à la base effectivement vu que le père fait en physique, ça fait une proximité
entre les bêtes.
Il faut peut-être effectivement faire impliquer les bêtes dans le recrutement des autres
de leur camarade ou compagnon.
Et ça c'est quelque chose qu'on fait aujourd'hui.
Et je crois que le père c'est très clairement un bonus au niveau de l'esprit d'équipe
de manière générale.
Après je crois que je me faisais la réflexion en préparant un métier.
Je me disais pourquoi est-ce que c'est pas plus répandu.
Et en fait il y a beaucoup d'analogies entre le métier de designer et le métier de
développeur.
Je pense que c'est des métiers où on doit à la fois produire quelque chose parce qu'il
y a des livrables qui sont tout à fait objectifs.
Mais je crois qu'il y a aussi quelque chose d'un petit peu moins enmesurable qui est
ce qu'on va dire l'inspiration ou la création.
C'est-à-dire qu'on pourrait faire le parocié de l'écriture qui est un exercice profondément
intellectuel.
C'est complexe et parfois comme tu le disais dans ton article très justement, en plus
on s'est censé faire deux mais la vérité c'est que quand on est dans des situations
de réflexion parfois un plus un ça fait zéro et parfois un plus un ça fait onze.
Et je crois que quand on travaille avec quelqu'un, quand on expose son raisonnement
à, je vais dire autre chose, c'est pas autre chose mais à son bilan dans l'occurrence,
je crois qu'on va plutôt vers un plus un égal 11.
En tout cas ça permet de, comment dire, de susciter la créativité, d'améliorer
quelque part tout simplement la génération d'idée.
Et je trouve que ça c'est vraiment un élément particulièrement vertueux de tout
ce qui est père.
Et moi comment, la question que je me pose c'est comment est-ce que tu en es arrivé
à ces choses là, comment tu les as ressentis ? Parce que souvent la première réaction
c'est plutôt de, tu vois c'est hyper tentant, tu as une équipe de deux, tu as un sujet à
traiter, justement tu les laisses débrouiller chacun un peu de son côté.
C'est une pente extrêmement glissante parce que chacun se spécialise d'un côté du
coup ça appelle à chaque fois à ce que ce soit cette personne là qui revienne dessus
et effectivement ça rend le projet extrêmement fragile parce qu'à la moindre perturbation,
une maladie, un départ, on perd énormément de connaissance sans compter que je vois
même pas comment il pourrait se diviser le travail en deux tellement il y a besoin de
cohérence dans un travail de design et de système mais ça a mis à part.
Quel a été ton chemin toi en tant que manager ou en tant que participant je sais pas justement
quand est-ce que tu as pris conscience de l'importance de ces facteurs là, à quelles
occasions ? Et déjà c'est pas mal ça, qu'est-ce qui t'a fait toucher du doigt ça en fait
parce que c'est un point de vue qui est assez rare en fait chez les managers.
En fait ça a été, j'ai connu des situations où il y avait un développeur qui était
expert d'un fichier, un fichier énorme, un fichier qui fait peur, un fichier où il y a
beaucoup trop de limites et trop peu d'écoutés et quand cette personne là, quitte le projet
ou change de mission voilà en fait on se sent un peu désempart.
Mais t'es un peu à poil en fait.
Exactement, exactement et en fait ça c'est pas des situations que normalement quand tu
les as vécues, t'as pas envie de bien vivre et c'est vrai que ça a un côté c'est un
éloge du court terme où en fait effectivement, oui sur la prochaine semaine, tu vas te
sentir confortable.
Sauf qu'en fait ta semaine tu vas la passer parce qu'en fait y'a pas de raison que tu
la passe pas, quelle que soit les choses qui arrivent mais par contre au fil des mois,
au fil des semestres en fait la petite boule de neige qui au début tout petit va rouler
va grandir et on va arriver à des situations qui deviennent sinon incontrôlables et qui
deviennent très coûteuses et en fait je pense que pour le coup c'est vraiment ce
cheminement là donc ça c'est une partie on veut dire c'est le vécu que j'ai eu en
tant que participe en plus dans les équipes ou en tant que contributeur ou déjà en
tant que manager ?
Non pas en tant que manager en tant que contributeur ou spectateur parce que c'est pas forcément
un équipe mais en tout cas je l'ai constaté et après il y a une, moi je fais beaucoup
de parallèles entre la conception technique et la conception fonctionnelle que je crois
qu'après il y a une conviction qui est assez profonde et c'est vraiment quelque chose
qu'on a écrit dans l'évition de l'équipe c'est qu'on est persuadé que c'est la
qualité qui fait aller le plus vite sur le long terme, un moyen et long terme, on est
persuadé que peut-être enfin, sur le court terme on n'a pas la réponse mais en tout
cas sur le moyen et long terme je pense qu'il y a des pratiques virtueuses qui sont des
gages de qualité et de rapidité et tout ça bien sûr c'est un truc à de choses dont
tu parles très souvent sur ton blog.
Alors pour moi ça fait aucun doute que même sur le court terme du travail de qualité
permet d'aller plus vite en fait mais quand tu dis plus vite il faut le regarder au global
et je pense que c'est bien ça que tu entaques c'est la notion globale c'est sûr la ligne
de code que tu es en train d'écrire si tu l'écris à deux là dans l'instant elle
te coûte peut-être un peu plus cher et il n'y a encore pas tant que ça mais en tout
tu cumules tous les avantages dont tu as parlé qui sont un peu invisibles en fait parce que
le code qui livrait ses tangibles la feature c'est tangible du bug c'est tangible mais
la connaissance c'est pas tangible du tout quoi.
Non.
Alors tu peux le voir tu as des...
Le moteur de carton.
En indirect c'est à dire que tu peux le voir dans la velocité de l'équipe si tu vois
que l'équipe ralentit dans sa velocité au sens c'est de plus en plus dur de sortir
de la feature et c'est de plus en plus coûteux à chose équivalente tu vas le voir en
fait mais c'est vrai que tout ça est assez peu visible et je trouve ça super que rassurant
en fait pas super rassurant qui est des managers pour qui ça soit une évidence en
fait parce que quand je t'écoute c'est l'impression que j'ai mais alors du coup ça me pose une
autre question qui est quand tu as ce point de vue là comment ça se passe avec l'équipe
est-ce que tu as été accueillis à bras ouverts est-ce qu'il y a eu du scepticisme quand
tu as mis ça en place comment ça s'est passé d'ailleurs est-ce que c'était dès le début
c'était comme ça on discute pas est-ce qu'il y a eu une phase de migration comment tu as
amené ton équipe et quelles sont les freins que tu as pu rencontrer
alors là où j'ai eu un petit peu de chance c'est que j'ai entregué les types de zéro
donc ça c'est parti entreguer du contrat initial
oui donc dès le débat c'était clair avec les devs que ça s'allait bosserais en perte
c'est ça c'est ça et même j'ai eu la chance là aussi d'avoir eu un encadrement on va dire
de nos archis qui était effectivement très rigoureux et que j'ai beaucoup questionné
j'ai beaucoup appris à leur rencontre parce que je crois qu'en fait les choses elles ne se
feront pas forcément naturellement j'avais eu ces expériences on va dire où j'avais du
des frictions mais je crois que si on y est marche aussi personnel quand on sait qu'on va devoir
traiter un sujet sur lequel on n'est pas forcément en maîtrise et moi c'est le cas par
un manager Bdev je n'avais jamais fait ça je ne suis pas l'expert on va dire en mode
de ces sujets là en fait il faut aller sur le blog de artisan développeur par exemple
non mais c'est vrai il faut suivre deux trois personnes sur l'edit il faut
aller parler aux experts enfin je suis à Chanson-Touais c'est une grande boîte où il y a des gens
qui ont des niveaux de séniorité tout à fait intéressants ils font profiter il faut aller
leur tirer la main je vais dire allez explique moi comment ça marche donc voilà et surtout
quels sont les pièges qu'elles sont les pièges à éviter en fait et je crois qu'en fait c'est
comme ça autant qu'un peu plus de sujets on va dire de développement fronde sur lesquels je
suis pas du tout compétent et c'est pas grave mais sur ce sujet là sur cette manière d'encadrer et
de poser un certain nombre de règles du jeu il de moi même en fait il doit ma posture à des
simples c'est comment est ce que je fais pour mettre les équipes dans les meilleures conditions
de travail possible et il en fait il en sait tout ce que c'est extrêmement facile d'avoir des
postures qui sont confortables en court terme et du coup et de mettre un développeur sous l'eau
de mettre l'accord de pouf enfin je sais pas comment dire ça sauf qu'en fait le rôle du
manager c'est d'éviter que ça s'arrive c'est d'éviter que ça s'arrive et ça demande de parfois
de prendre des décisions qui sont pas faciles mais là aussi il faut pas tomber dans l'éloge
du court terme il faut être je dirais conscient de ce qu'une mauvaise décision peut coûter et
au quotidien tu dirais que ton équipe elle elle binomme à quel pourcentage de temps quand il
bosse le design des bosse mi-temps trois quartant tout le temps je pense qu'on est entre
mi-temps et trois quarts puisque voilà fin globalement sur tout ce qui est nouveau composant ou
ou feature ou refonte sur un composant costaud il y a forcément du père parce que c'est vraiment
trop important par contre si on a une issue qui est un petit bug sur un comportement là ça va
pas être systématique en termes de le binommage ne sera pas systématique par contre si on sait si
c'est quelque chose à faire sur un composant complexe comme le composant tableau en application de
gestion en tableau de factures en composant important là effectivement c'est important que
les deux bêtes soient comme on dirait jamais au diapason sur les alliés sur voilà la nouvelle
manière de faire de ta qu'une problème et ton management est ce que d'abord tu en as parlé est ce
que tu n'aimes pas besoin d'en rendre compte est ce que tu es plutôt soutenu est ce que tu sens
des doutes comment comment c'est accueillé par ton manuel mais celle aussi je crois que j'ai la
chance les management soutient totalement soutient totalement la démarche et mon inclusion sont de
régulièrement ses équipes pour voir on va dire le niveau de qualité du code au-delà des indicateurs
objectifs bien sûr voilà donc nous on essaie de faire du mieux possible et tout ça que ça
consiste en amont avoir une conception carré mais ça c'est un débat mais voilà faire une
petite programmée du télévélier et quand c'est pas possible faire une test en tout cas voilà parce que
c'est les choses on va dire qui sont comme on dirait je vais commencer de faire le plus possible
parce que voilà en fait quand tu es n'as que de devs chaque problème je crois qu'avoir des ressources
restreinte aussi ça si on veut continuer à lancer il faut on va dire quelque part
faire le ménage devant sa porte tout simplement c'est la métaphore de la cuisine le fait de
restreindre les ressources c'est le c'est le seul moyen de pousser à la créativité d'aller chercher
des des gays en fait puisque tant que tu as une manière de faire régler ressources sont là
tu n'as rien qui te force à aller chercher à faire mieux alors que quand tu as une certaine
quantité de ressources que tu dis bon ok comment je fais pour faire 10 fois mieux parce que c'est
ce qu'il me faut pour atteindre mes objectifs bah là tu es obligé de changer de paradigme
pas toujours possible mais tu peux pas faire avec le truc qui marchait pour fois un pour un
poussant un peu tu peut-être faire fort à un demi fois deux parfois et en général avec un coup
humain non négligeable et du coup si tu veux faire fois 10 tu es obligé de changer de quelque chose
profondément en paradigme non et est ce qu'il y a des darts side ou des mauvais côtés au
père programming dont que tu perçois dans le quotidien ou dans l'équipe j'ai pas l'impression
j'ai pas l'impression parce que les designers aussi font beaucoup de paires donc c'est une pratique
qui est qui est un peu qui vraiment ancré dans l'équipe quoi qui est ancré dans l'équipe en
fait il ya je l'utilise enfin à la base le père designé j'utilisais pour un autre sujet qui était
vaincre la solitude du designer qui peut arriver parfois mais au final ça ça crée aussi on a
un design dans l'équipe qui parle de qui utilise beaucoup le terme higiene de travail en fait moi
j'aime beaucoup ce terme parce que la lige m'envoie bien ce que c'est je vois quand c'est propre
on comprend très bien ce qui se passe quand c'est pas propre et je crois qu'en fait c'est très
explicite c'est important d'avoir une bonne lige de travail et je crois que le le père de tdb
toutes ces choses on va dire que ce que je ne suis pas capable de faire en plus fortement moi ça me
semble vraiment des éléments fondateurs d'une bonne lige de travail pour me je suis complètement
aligné là dedans et je moi j'y intégrerai bien volontiers une lige en alors de vie au sens plus
large en fait tu vois des bases comme dormir et se nourrir et de manière équilibrée par rapport
à nos besoins qui sont tous un peu différents je l'inclus moi même là dedans tu vois la gestion
son énergie ça fait pour moi partie et les pratiques on font partie très clairement et tu nous as
parlé de paires de développeurs de paires de designers et ça arrive que un designer un
développeur bosse en paires aussi alors j'ai posé la question effectivement par rapport au sujet
du mobs ou quoi de ce soit ouais ou est-ce que la question qui suivait est-ce que ça arrive qui
travaille à quatre ça non pas non pour le coup ça ça arrive pas trop voir pas du tout
ils vont se dépanner mais ils vont pas s'asseoir devant un truc une tâche à faire et bosser à
plusieurs de sujets enfin en en mixant les coeurs les métiers quoi c'est ça c'est à dire que parfois
il va y avoir des balaces à arriver tout à l'heure mais c'était plus sur un sujet
qui a préamblé le rendu dans composants je sais c'est ça reste on va dire des tâches qui vont
être qui vont pas dépasser l'heure tu vas en gemma et c'est pas quelque chose autant ancré dans
la routine que le père à proprement parler est-ce que c'est un sujet dans l'entreprise est-ce que
les gens vous voient faire est-ce que du coup ça suscite de la curiosité est-ce que ça a
essémer pas du tout en fait votre portée fermée du coup personne ne voit vraiment ce qui se passe
que ça suscite quoi comme réaction dans votre entourage non je crois que c'est quelque chose
qui est connu qui on n'est pas du tout les seuls à faire ça je trouve extrêmement simple c'est
que si personne ne le faisait j'aurais jamais eu les mémoires de faire ça aussi c'est déjà dans
la culture de la boîte en fait c'est ça que tu veux dire voilà c'est ça après est-ce que
toutes les est ce que toutes les c'est pas forcément une culture dominante mais c'est
pas fait de vagues particulière c'est plutôt toi qui t'as inscrit dans le mouvement
c'est vraiment j'ai surfé on va dire sur sur la vague sur le cassement chip quand un certain
bonheur d'entom est venu faire une intervention chez nous enfin très clairement ça m'a bien
voilà tu parlais des éléments inspirants de l'intervention chez nous a été un élément
particulièrement inspirant pour moi et ça fait partie des choses en fait on se dit on
est bien sûr mais c'est bien sûr en fait c'est et si je me sentirais vraiment compable tu vois
très clairement moi en tant que manager si je poussais pas à la mise en place de ces pratiques
là et la vérité c'est qu'en fait non seulement il n'y a pas besoin de pousser et en plus je crois
que c'est même un facteur d'attractivité pour une boîte si on parle d'un jeu entreprise je crois
que les groupes d'auteurs ont envie d'aller dans des boîtes qui bossent bien parce que celles vont
demander de pousser le code là non mais que tout le monde a envie de bosser dans une boîte qui
bossent bien et personne n'est vraiment d'accord sur ce que ça voulait dire bosser bien donc c'est
là où il y a un problème un challenge et un défi mais tu vois sur cette question du minommage
je remarque même chez les dev c'est pas un sujet évident en fait beaucoup on sont curieux on
envie d'essayer peut-être certains le voient comme parce que c'est vrai que c'est beaucoup ancré
notamment ça vient de l'expert ou dans l'expert c'était c'était carrément prescrit en fait si
vous voulez bosser selon les règles de l'expert et tu bosses en minome tu vois un peu comme tu as
dans ton équipe je te pose pas la question c'est comme ça c'est dans les règles du jeu donc tu
joues au jeu auquel tout le monde joue quoi pour te dire même il recommandait dans les
bouquins les premiers bouquins il recommandait d'avoir vraiment un poste par développeur
enfin par père donc tu avais moins de postes que de développeur donc tu étais un peu obligé en
fait de binommer donc et c'est mais c'est pas forcément bien accueilli par tout le monde
parce que ça pour moi mon interprétation du point de vue des développeurs c'est que ça vient
beaucoup remettre en question dans une zone assez intime tant sur le plan physique que professionnel
en fait dans sa pratique et on touche à des préférences on touche à des choses qui sont
très finalement personnelles les gosses il ya les go qui vient s'emmêler mais même sans ça en
fait tu vois je veux dire le même quelqu'un qui est golesse qui arrive à mettre les go de côté
au cas par exemple ça c'est un truc que j'aimerais écrire là dessus sur la la
similitude qui peut y avoir entre l'impro et et le père programming dans le fait d'accepter
l'autre d'accepter la suggestion de l'autre ça c'est toi même si tu arrives à être assez égolais
c'est ouvert cette intimité elle est toujours perturbante moi quand je commence à binommer
avec quelqu'un j'ai toujours une petite appréhension au début que je dépasse parce que je sais que la
rencontre vaut le fait de faire ça mais tiens un peu une phase où tu vois je sais pas où tu te mets
un peu à nu quoi tu tu montres comment tu bosse des petites choses des petites des trucs que tu
fais pas bien tu sais que tu fais pas forcément bien mais tu n'as jamais tu as jamais pris le temps de
regarder vraiment comment faire mieux toutes ces petites choses là et qui qui est pas forcément
agréable en fait voilà tu as une petite phase où faut accepter de ouais faut accepter de rentrer
dans une forme dans une zone qui est assez personnelle et et ça je pense que ça reste en
fait je pense ça reste mais voilà moi je dis j'ai appris que ça valait le coup de passer par
cette étape là voilà donc c'est pour ça que je suis d'autant plus interpellé par ta ton point
de vue qui est qui est assez proche du mien je j'ai pas toujours pu même dans ma petite escène
promouvoir ça parce que le cadre des projets s'y prêter pas forcément mais très clairement
parce que tout simplement parce que mes clients 9 sur 10 c'était des startups et la durée de vie
d'un projet c'était entre quelques semaines quelques mois pour 9 sur 10 donc l'économie pour le
client était difficile à trouver en fait tu vois donc même moi je peux donner un contrat
argument à ça mais par contre dès que c'est sûr une logique d'édition dès que tu es sur une
logique où tu t'inscris dans une certaine durée pour moi ça fait aucun doute et même je te dis à
titre personnel je le vois très bien à court terme mais même dans mon équipe que j'avais le
binaumage c'était pas c'était pas forcément facile en fait c'était pas voilà c'est pas
d'ailleurs forcément c'est de constater que sur plusieurs années on en a fait décompouver mais que
c'était pas la norme quoi tu vois c'était pas le bien sûr je crois que c'est des rencontres en
fait c'est une rencontre et il faut une compatibilité c'est à dire que même des gens avec
qui je trouve très cool il faut arriver à binommer c'est pas forcément pas toujours évident
donc ouais c'est une pratique qui est encore compliquée et je trouvais ça j'ai trouvé ça
super d'avoir ton point de vue en tant que manager parce que ce point de vue il est malheureusement
encore trop rare les gens sont vraiment centrés sur comme tu disais le court terme de la production
mais encore une fois c'est le vécu qui nous qui nous forme en fait parce que j'entends dans ton
expérience dans ton parcours de vie tu dis ben ouais j'ai vu des projets se plantés ou en
tout cas être un peu en galère plus ou moins forte, violente parce que on perdait la connaissance
avec un départ mais tellement quoi moi je vois des fois des logiciels entiers qui se retrouvent
orphelins quoi et ça pose de je trouve un énorme aléa sur la suite du projet quoi
totalement
est ce que tu as envie de partager quelque chose avec les auditeurs sur le mot de la fin
non je crois qu'effectivement le binommage comment la vie je crois que c'est effectivement
c'est une rencontre je pense que ça passe déjà par je pense qu'il y a un sujet recrutement
derrière et le choix des membres de l'équipe derrière je crois que ça pose la question
de qu'est ce qu'on veut pour nos équipes de ce qu'on veut pour nos équipes de comment
est ce qu'on met des gens dans les meilleures conditions de travail possible et sinon on
recrute en défrontant pour l'équipe design system en troisième donc vous savez comment
on travaille dans notre équipe donc n'hésitez pas avec vous des géniaux mettra si tu as une
annonce on mettra le lien sinon on mettra tes coordonnées pour que les gens puissent te
contacter et comment tu prévois de les faire travailler ce triname alors en meub ou en perte
alternée bah écoute je sais pas enfin je crois que je vais je vais faire comme comme j'ai toujours
fait fin c'est un sujet sur lequel moi j'ai pas d'expérience professionnelle là dessus donc en
regardant un petit peu ce qu'il dit je demanderai je dirais des articles je demanderai à des dev chez
nous j'ai pas de si tu veux j'ai pas vraiment dit de pas d'idées préconciants quoi moi j'ai pas
dit des préconçus parce que c'est pas mon expertise première et quand ça se pressent
en trabe il faudra step up et trouver des conditions qui soient acceptables pour tout le monde
bah écoute ça tombe bien parce que avec adrien on est en train de rédiger un petit article aux
oignons sur le le meub programming et notamment toutes les différences entre le prl mom donc ça
devrait bien aiguiller ta réflexion c'est parfait tu vois j'ai déjà ma solution ça y est
merci nicolas merci benoît quand t'as t'as chez le diteur bah j'espère que tu as apprécié cet
épisode si comme tu as remarqué c'est ce subtil placement de produit où nicolas a fait la promotion
de mon intervention chez eux si toi aussi tu as envie que j'interviens de notre entreprise si tu
penses que je peux vous apporter des choses tu m'envoies un petit coucou sur LinkedIn ou par email
benoît arobazartisandeveloper.fr je te souhaite une bonne journée ciao