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 Victor Billet de Wilmer.
Victor, bonjour.
Bonjour, ben non.
Enchanté d'avoir sur le podcast.
Est-ce que tu peux te présenter en une minute pour ceux qui ne te connaîtraient pas ?
Oui, avec grand plaisir.
Alors, je suis aujourd'hui Product Manager chez L'Oréal.
Donc, Product Manager sur des produits IT, pas sur des produits cosmétiques.
Et donc, j'arrive de là après formation d'ingénieur qui m'a amené à faire du conseil
en sortie d'école, donc conseil organisationnel, conseil en transformation.
Et du coup, pendant ces quatre années de conseil, j'ai beaucoup bossé sur les
projets informatiques, des projets techs au sein d'administration publique, mais
vraiment avec un biais très, très disital et tech.
Et donc, j'ai adoré ces sujets-là, j'ai adoré l'agilité et comment on l'a fait
marcher.
Ce qui fait que du coup là, ça fait 8 mois que je suis chez L'Oréal sur ces sujets-là
à pousser et essayer de développer des applications informatiques qui amènent de la valeur dans
l'utilisateur final.
Et ce qui a accroché entre nous, ce qui fait qu'on est en train de parler là aujourd'hui,
c'est un article que tu as posti sur le TDD, où tu expliquais en gros à quoi ça servait,
comment ça fonctionnait et comment tu l'utilisais.
Et j'ai été interpellé en disant « Tiens, intéressant, voilà quelqu'un qui n'est pas
dev qui nous parle de TDD, ça m'a intrigué.
Je me suis dit « Tiens, comment est-ce qu'il en est arrivé à ça et quelle valeur tu perçois
toi dans le cycle de développement d'utiliser cette pratique ? »
C'est un point de plus important.
En fait, ça m'est arrivé plusieurs fois en tant que product manager, donc profil non-tech,
d'être confronté à des développements agiles qui fonctionnent bien au début.
C'est-à-dire on est efficace, on fait du sprint, on délire l'utilisateur et content.
Et en fait, un jour ou l'autre, tu te rends compte que ça patine un peu et plus ça
va, plus c'est dur de faire avancer les choses, de délivrer des nouvelles features.
Et en fait, le problème, je me suis réconquant, en fait, t'avais plein de petites régressions
qui s'accumulaient, que parfois tu faisais un dev sur une nouvelle feature et en fait,
ça faisait péter une autre feature.
Et en fait, je me suis rendu compte qu'on n'a pas vraiment de tests automatiques pour
tout vérifier.
Donc, soit c'était un PO qui a été testé à la mano, soit on allait, je sais pas, se
prendre une semaine pour juste vraiment faire du bug fixing à la main.
Mais en gros, d'une manière ou d'une autre, je me suis dit qu'on a un problème de qualité
sur notre logiciel et c'est ce qui m'a amené sur les sujets des DevOps.
Donc, je me suis dit, c'est simple, la gilne, pour faire de la gilne, il faut faire du DevOps.
C'est-à-dire, il faut que tu sois en capacité de pousser très rapidement ton logiciel en
production et ce qui veut dire que pour le faire rapidement, t'es obligé de te baser
sur des tests automatiques.
Puisqu'en fait, concrètement, si tu as besoin, si tu es dépendant d'un humain, ça va aller
moins vite, ça va être moins fiable, moins exhaustif et ainsi de suite.
En gros, la gilne m'a amené au DevOps et je me suis rendu compte que du coup, voilà,
il y avait ce besoin-là de faire du test automatique régulièrement.
Le problème, c'est que quand tu dis ça en général, on va te dire, ben ouais, mais en fait,
on a commencé son test automatique, du coup, comment je fais ?
Alors, en général, le réflexe, c'est de dire, du coup, la prochaine fois qu'on démarre
une application, on le fera bien le début et on fera du test automatique.
Mais le truc, c'est que du coup, c'est toujours difficile un peu de réussir à
pitcher ce truc, de réussir à défendre ce truc-là.
C'est pour ça que du coup, t'es aidé, j'ai le truc, c'est une discipline hyper intéressante,
parce qu'en fait, ça te permet de plus te poser la question de, je suis le test
automatique ou pas. En fait, t'es aidé, tu te dis juste, c'est une bonne manière de faire
du développement logiciel, c'est une bonne manière de concevoir ton application et en fait,
à la fin, tu tests, tu les as, mais c'est un bonus, quoi. C'est pas ça ce qui t'a poussé à l'avoir,
c'est juste qu'en gros, ça te permet d'avoir un truc qui soit fiable, vérifié à tout moment.
Et c'est ce que tu veux avoir quand tu fais de la gilne.
Donc, c'est pour ça que comme c'est un truc qui est un peu exotérique, en fait, moi,
quand j'ai commencé à m'intéresser à ce sujet-là, il y avait des Michael Aserat qui
en parlait beaucoup sur LinkedIn, mais en fait, je choisis tout le profil.
Ézotérique, attend, le terme est quand même assez fort. Ézotérique ? C'est quoi que tu trouves
ézotérique ? Non, mais c'est intéressant, dis-moi, comment tu...
Alors, ce que j'appelle ézotérique, c'est que c'est vraiment un truc un peu d'inicié,
en fait. C'est-à-dire que... Ézotérique, c'est les trucs où tu as des... Voilà, c'est un truc un
peu d'inicié de petits groupes qui le fais dans son coin. Et en fait, t'as l'impression,
quand tu viens pas du dev, en fait, c'est un truc vraiment un peu mystérieux, un peu mystique.
Et en fait, t'as beaucoup de choses sur... On fait des cérémonies avec des capuches,
des tenues sur des damiers. Oui, non, mais c'est un peu ce côté-là. Et moi, en fait,
moi, ma conviction, c'est qu'en gros, bon, en fait, moi, je suis PM, donc tu dis des dég,
clairement, je sais pas en faire. Par contre, je suis convaincu de la valeur que ça pour un
outil au final. Et quand je dis outil, c'est pour l'utilisateur. Donc, en fait, si je veux être
un bon PM, je vais délivrer un outil de qualité. Pour délivrer un outil de qualité, en fait,
il faut que je puisse, bah, défendre ses approches-là. Et c'est pour ça que, du coup, j'avais envie de,
bah, un peu, expliquer pourquoi c'est puissant comme approche. Pourquoi, en fait, on ne fait pas
juste pour arrêter des automatiques, quoi, parce pourquoi, en fait, ça te permet d'avoir un outil
qui soit de meilleure qualité à la fin. Et en fait, quand tu parles à des sponsors, à des gens
un peu haut placés qui ont, en fait, le pouvoir de faire avancer des projets informatiques,
souvent, ils ont une vraie méconnaissance de ce sujet, quoi. Et plus largement de, en fait,
que l'agile, c'est pas juste un process, c'est des sprints, en fait. C'est aussi être fort
techniquement. Et ça marche pas si tu ne l'es pas.
Moi, c'est quelque chose que je prêche depuis longtemps, et ça fait partie des raisons,
notamment, pour lesquelles avec Jean-Pierre, on s'entend bien. Jean-Pierre Lambert,
de la chaîne Scrum Life. C'est parce que c'est vraiment un de ses montrats, et je l'ai écouté,
il n'y a pas longtemps dans un live, et il commence par ça, il vient pour parler d'agilité,
il commence par parler d'excellence technique. Donc forcément, on s'entend bien. Et si on
récapitule le chemin, en fait, toi, c'est la fragilité des tests, c'est la non-qualité qui
t'amène à réfléchir à comment tu peux améliorer ça. Tu t'intéresses au DevOps. Le DevOps t'amène
à l'automatisation. L'automatisation t'amène au TDD. Et en fait, tu te rends compte que le TDD,
c'est bien plus que simplement automatiser ces tests.
Oui, exactement. En fait, il y a une étape un peu supplémentaire qui est qu'en gros,
je me suis dit, voilà, agir, ça ne suit pas, il faut faire du DevOps. Et en fait, DevOps,
c'est très compliqué quand tu as une application qui est un peu monolithique, qui est un peu dispatchée
sur différents infras avec des interconnexions dans tous les sens et que tu as du mal à bien
comprendre. En fait, ça va être très compliqué de faire des petites mises en prods incrementales.
À chaque fois, tu es obligé d'amener les rames et de faire ta grosse mise en production qui est
compliqué à faire. Et du coup, c'est là où je me suis rendu compte que tu as besoin aussi d'avoir
une appli qui soit très modulaire avec des coupes-plages. Il y a toujours des débats sur
microservice monite. La question, ce n'est pas ça, c'est plus en fait, tu as besoin d'avoir des
choses qui soient suffisamment découplées, indépendantes, pour pouvoir les mettre en production
de manière tranquille, en fait, et sans que ça impacte les autres. Et c'est là aussi que je me
suis rendu compte de la force d'aider, c'est qu'en fait, en essayant d'avoir des composants qui
soient toujours testables et qui t'es conçu comme tel, ça va te pousser à avoir une appli qui soit
plus modulaire. Et c'est ça qui va te permettre, enfin, voilà, ça qui va te permettre d'atteindre le DevOps,
c'est donc d'atteindre l'agilité. Donc en fait, c'est un peu ces deux bénéfices-là hyper forts,
que à la fois l'automatisation et puis à la fois, en fait, vraiment le côté des coupes-plages
dont tu as besoin aussi. Parce qu'en fait, ton appli n'est pas viable à terme si tu n'arrives pas à
atteindre ce niveau d'archite, enfin, de conception architecturale.
Je bois tes paroles comme du petit les. Moi, ce qui m'intrigue, c'est comment ? Enfin,
qu'est-ce qui fait que toi, à un moment donné, tu dis, c'est pas normal et on va essayer de résoudre
ce problème versus des tas de gens qui vont dire, bah ouais, c'est normal, c'est comme ça, c'est les
bugs ou c'est la vie, ça coûte de plus en plus cher. Parce que je vois des tas d'équipes
s'embourber et trouver ça presque normal, tu vois, juste y compensent par, en général, le chemin.
Là où toi, tu as fait la bifurcation DevOps, en général, les équipes, c'est plutôt,
bon, il nous faut détesteurs et on commence à recruter détesteurs et on tombe dans un espèce
de cycle de construire une équipe de QE. Non pas que la QE ne sert à rien, mais c'est au
contraire, c'est plutôt cette dynamique de dire, on en fait un espèce de silo indépendant qui va
grossir au fur et à mesure que tout simplement le plan test grossit, parce que ça devient plus
soutenable, jusqu'au jour où il se rend compte qu'en fait, il y a une limite aussi et toi,
toi non, tu dis non, allez hop, c'est là-bas que je pense que c'est mieux. Je suis curieux parce que
c'est pas le chemin classique et du coup je me dis, ouais, qu'est-ce qui t'as mis sur cette voie-là
en fait ? Je pense, t'as un peu de deux éléments, je pense que le premier c'est que, en fait,
pourquoi les gens le font pas, c'est que c'est dur quand même en fait parce que, en
moment, en gros, moi je me suis dit, je comprends pas très bien, c'est quoi une application
d'y coupler et là, en fait, t'es un peu obligé de rentrer dans des, t'es quand même obligé
d'entendre un sujet un peu technique, c'est-à-dire que DevOps, déjà, quand t'es pas déco, c'est
la base, c'est dur. Par contre, t'as des histoires de binaire qui se baladent, de déploiements,
de gestion de l'infra-d'environnement qui sont durs et donc en gros, vraiment,
moi, un des problèmes que j'ai eu sur le DevOps, j'ai galéré, en gros, j'étais obligé de me noter,
je me déteste sur une note, en fait, les mots que je comprenais pas et toutes les heures,
en fait, j'ai aller rechercher sur internet et c'est génial, je ne le connais pas tant que,
mais en fait, c'est vraiment dur, quoi. T'as des trucs, vraiment, tu galères un peu,
quoi. Donc, j'ai assez dur et en plus, les devs sont souvent très, enfin, en fait, les devs
sont souvent réticents à l'idée de voir un PM s'intéresser à ça. Souvent, en fait, on me dit,
bah non, mais en fait, c'est pas ton job, tu vois, c'est à moi de, enfin, commence pas à me piéter
sur mon sujet et qui parle d'une bonne, enfin, et en fait, je les comprends parce qu'en fait,
il n'y a rien de pire qu'un PM qui va essayer de t'apprendre à comment tu codes, quoi. C'est
juste que, parfois, en fait, t'as besoin d'en comprendre suffisamment pour pouvoir, en fait,
bah aider les gens, mais un peu de manière un peu, un peu, sauve-toit, un peu plus loin, quoi.
Donc, déjà, c'est le premier truc, c'est vraiment dur. Et le deuxième truc, c'est que t'as, enfin,
en fait, t'as quand même, voilà, moi, j'ai envie de délivrer des applications qui soient
excellentes, quoi. J'ai l'opera jamais Instagram ou le site d'Amazon, quoi, mais j'ai envie de me
dire, bah voilà, je ne suis pas UCNB, mais j'ai envie de courir vite, quoi. Et en fait, t'as pas
de gens qui vont satisfaire de dire, bah, je suis un logiciel, il n'est pas top, il n'est pas dingue,
il y a des bugs, les utilisateurs ne sont pas super contents, dans cinq ans, on va le remplacer,
et puis, ce n'est pas très grave, quoi. Et moi, j'ai pas envie, voilà, enfin, encore une fois,
en gros, on n'est pas Google, tu vois, enfin, voilà, on n'a pas l'argent Google, mais ce n'est pas
parce qu'on n'est pas Google qu'on n'a pas hâte d'essayer et de faire des belles applications
et d'essayer de, bah, de, ouais, de rendre quelque chose d'utile à l'utilisateur. C'est ça un peu ça,
le point et cette zone de confort, en fait, que j'ai envie de dépasser.
Alors, déjà, là, c'est, ce que je retrouve, c'est une certaine quête d'excellence,
qui est quelque chose qui est vraiment un des piliers de l'artisanal logiciel du craft.
Donc, j'ai l'impression que ça, ça t'appartient et que c'est chouette,
d'ailleurs, je ne peux que t'en féliciter. Donc, le moteur, c'est un peu cette envie de bien
faire et d'aller plus loin et de toujours faire mieux. Et après, d'ailleurs, tu en décous avec
des concepts et tu y vas et tu rentres dedans et ça, c'est, voilà, c'est un travail comme tu dis
qui est dur et qui est impliquant, c'est top. Qu'est-ce qui te met sur la voie du DevOps ? Comment
à un moment donné, parce que tu as, tu arrives là-dedans, plutôt dans l'agilité, dans l'orgas,
tout ça, là, tu rentres, tu passes un peu une barrière qui est dans une thématique beaucoup
plus technique. Comment est-ce que tu en arrives à te dire, tiens, c'est un sujet intéressant à
creuser et je vais m'acheter ce premier bouquin ? Moi, c'est vraiment le côté
mis en production. En gros, il y avait un truc qui coincait au niveau mis en production.
T'avais un énorme pain point chez vous sur ça ?
Oui, on avait du mal. C'est-à-dire, enfin, il s'améryait sur plusieurs trucs différents,
mais en gros, voilà, c'était soit en fait, on mettait trop de temps à déployer ou à préprôtre.
En gros, le truc était en dev et puis, tu vois, c'était un peu comme le Cropy.
Puis, en fait, le moment où tu poussais en préprôtre, ça ne marchait pas. Donc,
peut-être que là, à ce côté-là, je chantais qu'il y avait un vrai problème là-dessus.
Et là, les dev ils disent quoi à ce moment-là ?
Les dev me disent, enfin, mais très naturellement, c'est compliqué.
Non, mais c'est juste, c'est compliqué. On a accumulé trop de retard.
Et donc, en fait, en gros, et en fait, à un moment,
du coup, on n'est pas là pour terminer cette feature.
Donc, en fait, je trouve que ce qu'on la termine et puis ensuite, on poussera.
Et enfin, en gros, tu fais ça, mais sauf que c'est la course en avant.
En fait, tu es tout le temps en train de tuer en avant.
Tu as toujours en temps envie d'en mettre des trucs.
Et donc, c'est un peu ce truc-là.
Et donc, en fait, je me suis dit, mais oui, en fait,
c'est vrai que l'agilité, quand tu regardes les gros bouquins de Couton d'Agyle,
en fait, ils n'avorent pas de manière très spécifique ce sujet-là.
Là où, en fait, devops, vraiment,
je n'en vois pas où c'est du devops, de dire quelque part.
Alors, le point que je n'ai toujours pas capté,
alors, j'ai compris que tu avais senti qu'il y avait un point de douleur.
Visiblement, ton équipe, elle est plus d'un mode,
ben, oui, ce n'est pas top, mais on va quand même rester comme ça.
Et comment, à ce qu'à un moment donné, tu as atterri sur le devops ?
Moi, c'est ce moment-là un petit peu que...
Est-ce que tu t'en souviens ?
C'est quoi ? C'est que tu fais des recherches,
à un moment donné, tu vas sur Google et tu dis, comment pousser en prod ?
Tu commences à chercher autour de ces problématiques de douleur, de mise en prod ?
Ouais, c'est vrai.
Enfin, c'est vraiment, en gros, j'ai commencé à chercher sur...
Enfin, en fait, tu as quand même des frameworks, genre safe,
ou XP, qui te mentionnent un peu ces histoires de déploiement, tu vois.
Et qui t'amènent un peu ce mot-là, enfin, en gros, ce terme de devops.
Et du coup, c'est à partir de là que, du coup, tu crois...
Mais après, moi, en gros, j'achète pas mal de...
Enfin, je jouais, t'es assez curieux sur ces trucs-là.
Et donc, ça m'arrive souvent, ça m'arrive plus souvent d'acheter un bouquin sur un sujet
qui n'est pas important pour moi que de pas acheter un bouquin sur un sujet qui est important.
C'est-à-dire qu'en fait, tu le mets à ou de n'autre,
à un moment, le truc est un peu dans l'écosystème et ça m'a intéressé.
Mais ouais, c'est vraiment...
T'as quand même des frameworks qui vont un peu plus loin que juste la partie développement âgée,
les qui te poussent à aller vers du devops.
Et c'est ça, le truc un peu qui m'a dit,
mais attends, ça me ptit, je comprends pas très bien,
mais j'ai l'impression que ça peut résoudre mon point de douleur au niveau du misère production.
Ok, c'est top.
Et alors, maintenant, 8 mois, où est-ce que tu en es par avoir ça ?
Est-ce que tu l'as expérimenté en vrai d'avoir une équipe qui faisait du TDD ?
Comment est-ce que tu passes une équipe qui n'en fait pas du tout ?
À une équipe qui en fait pas...
Parce que tu as quand même un rôle majeur en tant que PM,
dans le pouvoir de décision, dans la pression que tu vas mettre sur l'équipe,
dans la bande passante qu'elle va pouvoir allouer à autre chose que de la production de features, de valeur.
Comment est-ce que tu racontes nous un peu ton voyage là-dessus ?
Aujourd'hui, en fait, oui.
Aujourd'hui, en fait, je suis assez confortable sur ma posture qui est de dire,
en tant que PM, j'ai le droit de pousser,
enfin de dire en fait, je veux que les choses soient bonnes techniquement,
soit que c'est en techniquement.
Et en fait, du coup,
je suis dans un contexte quand même où j'ai la possibilité de pousser pour les choses là,
et en fait, en gros, j'ai eu des...
Par le passé, en fait, j'ai eu des fois où vraiment,
on était sur des histoires de budget très très serrés,
où en fait, c'est très très dur dans ces cas d'expliquer un petit peu
aux sponsors qu'on va devoir passer un peu plus de temps pour être meilleur techniquement,
mais que c'est la meilleure manière de faire quoi.
Même si, en fait, à l'évite, pour aller vite, il faut aller bien, c'est difficile à expliquer.
Alors que là aujourd'hui, j'ai un peu plus de l'attitude,
ce qui me permet de pousser ces choses-là.
Il y a deux éléments, on a premièrement ce truc là,
c'est-à-dire que comme j'ai plus de marge de manoeuvre,
c'est plus simple de pousser pour ce genre de pratique.
Parce qu'en fait, en gros, on laisse plus de liberté
et on est en bon partenariat avec nos équipes de dev,
ce qui nous permet de dire qu'on teste des trucs qui sont appris puissants et efficaces,
mais on le laisse même un peu parce qu'on n'a pas tout l'habitude.
Ça, c'est le premier truc.
Donc ça, ce que tu dis, c'est qu'il faut quand même un cadre
qui le permet d'un point de vue budgétaire,
c'est-à-dire de se permettre d'investir sur ces choses-là
et d'essayer de faire des expériences sur tout ce truc-là.
Ouais.
Et là aujourd'hui, tu l'as.
Et donc du coup, comment est-ce que tu passes d'une équipe ?
Est-ce que déjà, tu as eu ce retour d'expérience d'une équipe qui bossait en utilisant du TDD ?
Et comment est-ce que tu l'as amené, cette équipe, à passer au TDD ?
Moi, je suis moins en détail maintenant quand même les équipes de dev,
mais en gros, en fait, maintenant, ce qui est marrant,
c'est que le chiffre, c'est qu'en fait, les équipes,
enfin les boîtes avec lesquelles je bossais,
ils me disent qu'on bosse en TDD nativement.
Donc en gros, du coup, il y a assez de sortes de chiffres
qui fait que c'est même pas un truc que j'ai besoin de demander.
C'est un truc, en fait, qui utilise un peu selon le contrôle des débuts.
On va travailler comme ça.
Attends, attends, attends.
Mais ça veut dire quoi ?
Ça veut dire que en fait, le moment de la transition,
ça se passe comment ?
C'est en fait, en arrivant dans ta nouvelle boîte,
tu remets un peu les compteurs à zéro.
Et par contre, à partir de là, les gars, tu les choisis,
ça devient un critère de choix.
Ça devient limite un critère de choix.
Et en fait, en général, les boîtes avec lesquelles je bosse, en fait,
en tout moment, quand on a des prestats,
en fait, les prestats te disent, nous, on bosse en TDD de base.
Ce qui fait qu'en fait, c'est une donnée de l'équation dès le début.
Enfin, je n'ai même pas forcément besoin de pousser pour ça.
En fait, le truc, par contre, le truc pour lequel il faut...
En fait, maintenant, c'est un peu une donnée de l'équation.
Le truc pour lequel il faut...
Je peux pas objeter de me battre maintenant.
C'est en gros de se dire, en fait, on a les outils techniques
pour pousser rapidement des choses en prod.
On a le cloud aussi.
Tout ce qui est cloud serverless, c'est vraiment...
Enfin, c'est génial là-dessus.
Ça veut dire que c'est beaucoup plus simple de faire des pipelines
et puis de déployer très rapidement sur différents environments.
Le truc sur lequel moi, j'ai besoin de pousser maintenant,
c'est plus de se dire, en gros, on va réussir à faire du small batch, vraiment.
C'est-à-dire faire des petits incréments, des vrais petits incréments.
Réussir à développer des petits trucs fonctionnels
et les montrer très vite aux clients.
Réussir du feedback très rapide.
Donc, en gros, je vais dire quelque part,
je commence à avoir l'infrastructure technique qui permet de le faire.
L'excellence qui commence à arriver.
Maintenant, il faut réussir à transformer l'essai.
Pour dire, je l'utilise pour vraiment aller confronter très vite
à mon utilisateur final et à un petit peu de feedback rapide.
Parce qu'aujourd'hui, tu dirais que ton cycle de feedback,
tu l'estimais combien ?
Entre le moment où tu as une idée, tu dis,
« Ah, ça serait vraiment… »
Voilà, il faut qu'on fasse ça et qu'on voit si ça donne quelque chose.
Et le moment où tu peux commencer à collecter de la data,
parce que ça a été développé, poussé en prod,
mis dans les mains des utilisateurs.
Holettement, honnêtement, on va être deux, trois semaines minimum.
Difficile de gérer.
Deux, trois semaines.
On est sur un an de grandeur de quelques semaines.
Et toi, tu viserais quoi ?
Qu'est-ce que tu aimerais ?
Moi, pour moi, en gros, il faut être à la journée.
C'est le truc où après, il y a toujours les sujets,
ton utilisateur n'est pas dispo, je ne sais pas quoi.
Mais idéalement, tu vois…
C'est un gros objectif où tu dis « Tiens, tu enlèves un ordre de grandeur ».
Oui, exactement.
Pour moi, c'est ça le truc.
En fait, c'est vraiment…
La GC, c'est ça, au final, c'est en gros ton utilisateur.
Il ne sait pas ce qu'il veut, donc tu as besoin de lui montrer.
Et donc, tu crées une appli qui est tout le temps déployable.
Tu la déploies tout le temps, tout le temps, tout le temps.
Il te fait des feedbacks tout le temps.
T'es t-il là ? C'est t-il là ?
Et du coup, tu vois, c'est là que tu vois que la notion de roadmap,
ça a plus de sens.
C'est un sens d'une certaine manière.
Mais en fait, l'idée, c'est vraiment de se dire.
Voilà, j'ai besoin de tirer très, très rapidement pour réanter ça vers la valeur.
Et la valeur, c'est l'utilisateur final qui me l'a donné.
Oui, j'adore.
C'est extrêmement puissant.
Et j'aime bien ta manière de voir le truc en disant le…
Maintenant, j'ai l'infrastructure qu'il le permette.
Avant, je ne l'avais même pas, donc j'essayais même pas d'aller plus vite.
Maintenant que j'ai l'infrastructure,
je vais l'utiliser à 100% et voir jusqu'où je peux aller de réduire ça.
Vous êtes toi.
Et est-ce que tu as eu…
Au moment où tu prends…
Donc, ce que je comprends, c'est qu'aujourd'hui,
ce n'est plus une donnée du problème.
Du coup, j'ai deux questions pour toi.
Est-ce que ça a un impact sur les budgets, sur les TG, des GAQs que tu embauches ?
Est-ce que tu as l'impression que c'est que les…
En gros, est-ce que tu es prêt à mettre plus d'argent ?
Parce que les gens travaillent en utilisant cette pratique-là,
ou est-ce que ça te pousse à aller vers des cabinets
qui pratiquent des prix un petit peu plus élevés ?
C'est la première question.
Ouais, le réponse, c'est la question après, j'en ai une interprète sur la transition.
Ça n'a pas énormément changé, je trouve.
Pas beaucoup.
Donc, finalement, avoir de la qualité coûte pas beaucoup plus cher.
Non, tout à fait.
Ça n'a pas trop trop…
Non, et je pense qu'en fait à un moment,
toutes les boîtes qui font du DEF, qui font de la Presta,
à un moment, je pense, sont rationnelles.
Ils se rendent compte que c'est plus efficace à un moment.
Tu vas à un moment où tu es un peu obligé de s'y fêter de main-set.
Et donc, du coup, je trouve que non, ça va.
Par contre, c'est vrai que moi, du coup, j'aime bien voir des petites boîtes,
tu vois, des petites boîtes de Presta, où peut-être ils ont 20-30 personnes,
et tu vois, tu sens qu'eux, ils aiment vraiment beaucoup ça.
C'est pas un truc plus rationnel,
où en fait, mon client sera plus content à la fin.
C'est vraiment…
Ils adorent ça, tu vois, ils te disent,
« Ah ouais, le craft, c'est un truc, ils en parlent, ils font des events là-dessus.
Enfin, moi, j'ai toujours cette sensibilité-là par rapport à ce genre de boîte.
Mais globalement, c'est plutôt assez difficile à penser démocratisé. »
L'autre question que j'avais pour toi, c'était dans la transition.
Ce que je comprends, c'est qu'aujourd'hui, c'est plus un sujet,
parce que ça devient presque un critère de choix.
En tout cas, les gens avec qui tu bosses, c'est même eux qui te le poussent.
Mais au moment où tu prends conscience de ça,
au moment où tu prends conscience que c'est difficile,
que tu as un point point, que tu as envie d'aller dévoluer,
tu as ton équipe qui, je suppose, par défaut, n'en fait pas,
comment est-ce que tu amènes le sujet et quelle réaction tu as en face de toi ?
Quel résultat tu obtiens après ?
En fait, c'est marrant parce qu'ils ont...
Alors, ils faisaient ce que je pense que Michael Azar,
il appelle un peu le test, test last development,
en gros, ils n'aient pas des petits cycles de TDD,
Red Vendry Factor, en fait.
Ils écrivaient tous leurs tests au début,
et puis après, il y avait un gars qui connaît,
enfin, un peu en mode comme ça.
Honnêtement, c'était très dur,
enfin, c'était très dur parce que le coup là,
le problème, c'est que moi, je n'étais pas légitime
pour pousser un...
En fait, déjà, si les gars disent qu'ils font des TDD,
mais que ce n'est pas du vrai TDD, c'est hyper dur du coup de...
Ah oui, c'est-à-dire que les mecs, ils prétendaient en faire déjà.
En disant, en fait, tu sais, c'est tout classique,
où en fait, ils font test first, tu vois,
et après, du coup, tu as des tests,
enfin, il y a quand même des tests au début,
et donc, enfin, en gros, quelque part, tu les as...
Donc, tu avais quand même des tests ?
Tu avais des tests...
Ouais, tu avais des tests fonctionnels.
Tu avais des batteries de tests, mais en fait,
si tu veux comme le...
En fait, comme, en gros, les tests sont faits tout au début,
bah en fait, ta ce côté quand même architecture spaghetti,
qui fait que la valeur ajoutée,
enfin, tu vois, tu es beaucoup moins puissant
qu'en fait, si tu arrives à avoir tout bien découplé,
tu vois, avec des petits tests qui émergent au fur et à mesure, quoi.
Ah ouais, donc c'est encore plus dur,
effectivement, c'est encore plus dur de venir leur dire,
bah vous le faites, mais en fait, vous faites de la merde, quoi.
Et l'autre cas, alors, et ça, c'est un des cas que j'avais eu,
et t'avais effectivement d'autres cas où les gars n'osait pas,
et en fait, là, c'était, bah, quand on m'a parlé,
c'était, bah en gros, il faut payer plus cher, quoi.
Enfin, ça s'arrête forcément plus cher, quoi, à l'époque.
Et je pense, en fait, et là,
pourquoi je pense que ça aurait été plus cher,
c'est plus qu'en fait, comme les gars étaient pas formés,
enfin, à ça où avait pas forcément l'habitude d'en faire,
c'est sûr que, bah du coup,
t'as eu un cours d'apprentissage un peu à payer.
Ouais, mais sûr, voilà, bien sûr,
t'as un coût d'acquisition de la compétence.
Et aussi, un truc, c'est qu'en fait, c'est très, très dur, je pense,
d'avoir l'humilité, quand en fait, quand t'es un peu celui,
enfin, quand t'es maitrice d'œufs, c'est-à-dire, voilà,
quand t'es, ceux qui apprends t'es développeur,
c'est très dur d'avoir l'humilité de dire,
bah en fait, on faisait pas les choses bien, faut faire du t'aider, et quoi.
Et ça, c'est pas, enfin, ça, c'est un truc qui n'est pas facile,
et je comprends effectivement, en termes de posture,
tu vois, il y a eu ton client, c'est hyper dur d'assumer,
mais s'il te plaît, il te dit, bah ok, on va changer pour faire les choses
bien parce qu'avant, on les faisait pas bien.
Ouais, donc le moyen que t'as trouvé,
c'était de changer d'environnement.
Ouais, tout à fait.
Bah écoute, merci Victor pour tout ça, pour ce retour d'expérience,
c'était assez riche, et j'ai beaucoup aimé ton point de vue en tant que PM.
Si les auditeurs veulent en savoir plus sur ce que tu fais,
et te retrouver, ils peuvent venir où ?
Alors, sur LinkedIn, Victor Biette de Viver,
comme ça se prononce, je publie très régulièrement,
tout le jour, sur les sujets liés à l'agilité, la technique,
et digital en général.
Et du coup, je suis le royal, on recrute sur des postes de tech,
PM, Data Scientist, Sautifair Engineer, Architect, tout ça.
Donc voilà, n'hésitez pas à me contacter aussi à ce sujet-là.
Merci Victor.
Merci Vodou.
Quand t'attaches à l'auditeur, bah écoute, comme t'as aimé cet épisode,
si c'est le cas, tu peux m'envoyer un petit mot,
ça fait toujours plaisir,
penoiearobazartisondev.fr, ou sinon,
je dois être assez joignable comme sur LinkedIn.
Voilà, un petit mot pour me dire ce que tu as aimé,
ce que ça t'as apporté.
Ça, je pense que, en plus, c'est un épisode qui est typiquement,
qui se prête bien à une écoute partagée.
Tu proposes un café, une écoute partagée,
tu emmènes un peu de bouffe,
c'est un truc qui marche toujours avec les devs.
Tu emmènes des bonbons, des sucreries,
des bars de chocolat, etc.
Et tu leur proposes d'écouter et de faire un petit débat après,
et qui sait ce qui fera se passer.
Et sinon, si tu as envie d'accompagner,
que ce soit toi, d'apprendre à écrire du code durable,
ou ton équipe à écrire du code durable,
eh bien, je t'invite à venir découvrir le cursus artisan développeur,
dont je te mets le lien en description.
Allez, bonne journée, ciao !