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 Benjamin Brizzi.
Benjamin bonjour.
Bonjour, merci de m'accueillir.
Je t'en prie avec plaisir.
Est-ce que tu pourrais te présenter en quelques mots pour ceux qui ne te connaîtraient pas ?
Alors, je m'appelle Benjamin Brizzi.
Je suis responsable de l'équipe Tech chez Fleet.
Je suis VP Engineer.
Aujourd'hui, je gère une équipe de cinq développeurs organisées avec une équipe
produit de trois product.
Moi, je suis arrivé au début de Fleet, donc pour monter la première version de la
plateforme qu'on a actuellement.
Alors, Fleet, ce que c'est, c'est une entreprise qui fait du leasing d'ordinateurs et de
smartphones pour les entreprises.
Donc, on offre à la fois une offre financière qui va être du leasing sur trois ans des
appareils pour pouvoir les redouveler.
Et ce sur qu'on passe au plus de temps en dev, c'est une plateforme de gestion de ces
appareils, de gestion de son parc informatique pour tout se suivir.
Oui, c'est un vrai pour les gros clients.
Ça, c'est un vrai pour les gros clients.
Pour les clients.
C'est quoi tes clienties?
J'ai l'image de deux clients.
Soit le client qui a une énorme base de matériel et qui n'a pas tellement envie de
s'embêter, soit l'entreprise qui bouge beaucoup typiquement startup, scale-up,
qui a besoin de beaucoup de matos.
Oui. Alors, nous aujourd'hui, on est plus positionné sur scale-up startup.
À partir d'un appareil, on ne fait pas les autres entrepreneurs parce que d'expérience,
c'est complexe, c'est bien financièrement sur le risque, etc.
Et en fait, on a essayé de cibler des clients un peu plus gros, mais soit ils vont
interniser leur IT et donc avoir une personne qui gère ça en interne à temps plein ou
même à temps partiaire qui vont finalement avoir presque plus de valeur ajoutée que nous.
Et les très grosses boîtes vont avoir des services de gestion avec des gros
grossistes de matériel qui vont gérer ça pour eux.
Donc nous, voilà, notre usur-persona, ça va être l'office manager qui gère un parc
de MacBook dont c'est pas forcément le boulot, qui ne sait pas trop comment choisir
les ordinateurs, qui n'a pas envie de le faire pour qui ça prend du temps de le faire
et faire gagner du temps à ce genre de personnes.
OK, c'est cool. Et du coup, je crois que je t'ai coupé et tu allais dire un truc encore.
Non, dans la présentation.
Donc moi, je viens du parcours plus traditionnel, on va dire, entre guillemets d'ingénieurs.
J'ai fait une école d'ingénieurs à l'île et je suis autodidacte en dev.
Donc j'ai commencé, moi, j'ai 36 ans aujourd'hui,
donc j'ai commencé au lycée vers 2000 à faire des premiers fans.
Ça étant en HTML comme comme pas mal de monde, je pense.
Et maintenant, c'est mon boulot, voilà, parce que c'est toujours une passion.
Alors, au menu, tu as amené sur la table quelques
quelques thématiques que je trouve super, toutes super intéressantes que j'adore
aborder dans le dans le dans le podcast.
Par quoi tu as envie de commencer?
Par le recrutement, c'est le début, le recrutement.
Allez, vas-y, le recrutement.
Donc, comme je l'ai dit, moi, je suis arrivé premier, premier, premier développeur.
Donc moi, j'ai eu un certain plaisir à faire la première version de la plateforme
de partir from scratch.
C'est toujours.
Et quand tu arrives, tu as quel niveau d'expérience déjà?
Alors, donc comme je disais, 36 ans, je suis arrivé à 3 ans.
Donc avant, j'étais chez Blissime.
En gros, une dizaine d'années d'expérience.
Voilà, c'est ça, une dizaine d'années d'expérience.
J'avais fait beaucoup de PHP.
J'avais fait du GES en front.
Et là, je suis arrivé.
Alors, il y avait un MVP, on va dire, de Cit vitrine.
Je suis arrivé sans stack React Node.js.
Donc j'ai pu apprendre pas mal de choses, j'ai apporté même.
Et donc assez vite, on est besoin de recruter avec des coûts assez limités.
Et mon boss, c'est un ancien chez Aeronac.
Donc ce qui ne passe pas à Aeronac, c'est une formation de reconversion.
Enfin, pas mal pour les devs en reconversion.
Donc c'est des formations courtes.
Comme on en voit pas mal apparaître en ce moment.
Et donc, c'était un peu la source logique pour le recrutement de passer
par des étudiants d'Aeronac.
On avait un partenaire privilégié avec eux.
Et donc, j'ai pas mal de change sur ces recrutements.
Donc on est passé d'abord par des stages ou des contrats courts.
Du fait qu'on est une boîte boost-trappée, qu'on n'a pas forcément un budget énorme.
Donc, voilà, c'est en fait toujours un compromis entre passer plus de temps à former
versus avoir quelqu'un opérationnel tout de suite mais qui va être plus cher.
Donc on a pris la première option parce qu'on avait plus de temps que d'argent, on va dire.
Et voilà, donc j'ai eu pas mal d'aventures.
On va dire avec...
Alors pas, j'ai cité Aeronac, mais on a bossé avec pas mal d'autres formations de ce type-là.
Donc avec...
Et en fait, le problème de ces formations,
alors est-ce que c'est un problème ou est-ce que c'est au contraire quelque chose de positif ?
C'est que c'est ouvert à tous, il y aura tous types de profils,
des gens qui sont là pour les bonnes raisons ou pour des mauvaises raisons.
Et ce que j'ai remarqué, tu me diras ce que tu en penses,
c'est que le métier de Dev, il s'est énormément démocratisé.
Et aujourd'hui, c'est un peu vu comme le métier magique où il n'y a aucune barrière à l'entrée.
C'est très bien payé et tu as besoin de rien pour commencer.
C'est quoi ?
C'est pas complètement faux et il y a en même temps d'un point de vue opérationnel,
c'est pas complètement vrai non plus.
Ce qui est vrai, c'est qu'aujourd'hui, tu peux être Dev sans avoir fait de formations fondamentales.
Sur le sujet.
Alors c'est l'image que ça, moi j'ai plusieurs personnes dans mon cercle personnel qui sont venus me voir
et me dire, j'ai commencé à apprendre le Dev sur Open Classroom, sur tel truc,
que ça a l'air simple à prendre en main.
Et quand tu vois que les postes entry level, c'est 40 000 euros et le gars, il est sur un boulot
pas forcément bien payé pour se dire, bon, rester dans un bureau et faire un truc qui a l'air simple,
ça sert bien, mais en effet, je suis 100 % d'accord.
Ça fait que c'est cette image là, mais c'est beaucoup plus compliqué que ça entre faire ta première page HTML
qui en effet paraît abordable et gérer un peu.
Non, c'est clair, c'est clair.
Tu vois, ça me fait penser quand la première fois que j'ai fait du béton,
c'était pas longtemps, parce que j'avais pas trop besoin.
Première fois que j'ai fait du béton, j'étais à la fois émerveillé de la simplicité de cette technologie,
parce que je pense qu'on peut dire que le béton, c'est l'OTEC, tu vois.
Et pour moi, c'était une aventure extraordinaire.
Mais, finalement, j'ai fait mon premier truc, c'était une réparation dans le trou, dans un mur.
Bon, voilà, j'avais fait mon petit mortier, j'avais eu un petit peu de béton et c'est passé.
Et là, je me suis fait cette remarque.
C'est bon, je sais faire du béton, mais c'est pas pour ça que je suis maçon.
C'est pas pour ça que je saurais construire une grande barraquée.
Et encore moins que je vais être architecte et capable de te construire un animal.
Et c'est un petit peu pareil, je crois en info.
C'est-à-dire qu'aujourd'hui, les frayemois, les langages ont arrivé à un niveau d'abstraction.
Que oui, tu peux effectivement apprendre à faire et tu n'as pas besoin de faire, par exemple,
parce que j'ai fait une formation hyper fondamentale où, moi, dans mes études, j'ai construit un ordinateur de Hazard.
C'est-à-dire, on a construit des microprocesseurs en BIOS, une carte mère.
Un système d'exploitation, un compilateur.
J'ai fait toutes les couches, toutes.
Et c'était hyper riche.
Et j'ai mis du temps à me rendre compte à quel point ça me servait au quotidien.
Mais on peut aussi très bien faire ça aujourd'hui.
Par contre, je pense que celui qui fait ça, il va plus galérer.
La moindre difficulté technique, il va buter.
C'est-à-dire que cet investissement, qu'il n'aura pas finitiellement, il faudra qu'il fasse dans le temps.
Et donc, il compense.
C'est ça.
Et le fait qu'il y ait un essor de ces formations courtes, forcément, t'as pas le temps de construire la carte mère.
Ah bah non.
Bah non.
T'as à peine le temps d'effleurer comment tu utilises une techno alors que tu envoies une par semaine pendant un semaine.
Moi, le recul que j'en ai, parce que quand j'avais mon studio, on a eu, on a eu fait appel à ça.
Mon premier employé vient d'une reconversion.
Ça a été un paris gagnant.
Mais derrière, on en a essayé une dizaine et ça, il n'y a plus une match, en fait.
Oui.
C'est le fait de la décom...
Des démocratisations, c'est qu'il y a un écart de skill énorme.
Énorme.
Ceux qui font ces formations pour qui ça fonctionne.
Et ceux que tu ne vois même pas sur le marché de l'emploi parce qu'ils font la formation, ils arrêtent au milieu ou ils se découragent ou ils se rendent compte que ce n'est pas pour eux.
Moi, pour moi, un gars qui sort d'une formation comme ça pour qu'il soit productif.
Et si quelqu'un entend ce podcast et pas du tout d'accord avec moi, je lui donne le micro très volontiers.
Mais j'ai été allonné un truc à deux ans.
Alors après, selon le niveau du mec, s'il est plus smart, s'il est plus passionné et qu'il bosse dur, que ça percute plus vite, ça peut être réduit.
Mais pour que le mec arrive à produire vraiment du code de prod que tu puisses pousser sur Master Tranquissory.
Voilà, j'étais à Bac, il faut deux ans.
Donc il faut...
Ça a un gros investissement en fait.
Et déjà, question en force de ce deux ans.
J'ai peut-être pouvoir un peu te contredire.
Vas-y.
Je vais chercher à quelqu'un pour te contredire.
Moi aussi, la première personne que j'ai recrutée chez Fleet, c'était donc il y a deux ans et demi.
Donc c'était deux ans et demi qu'elle est chez nous.
Et on a mis du code en prod la première semaine.
Alors, je précise, c'est qu'à l'époque, le projet était très simple.
Le projet avait six mois.
Donc moi, j'ai fait attention dans mon stack à ne pas mettre de complexité.
Donc on fait que du JavaScript pur versus du TypeScript.
On va en discuter aussi.
Ça, c'est encore un autre sujet.
Donc c'est du JavaScript front, de JavaScript back.
Il y avait à l'époque un site vitrine qui est très simple, ce qui est quasiment que des composants statiques.
Sur lequel voilà, on peut moiter en compétence assez vite.
Notre plateforme de gestion, elle faisait trois pages, une page utilisateur, une page pour réaliser l'appareil, etc.
Donc cette personne, elle a un peu grandi avec le projet.

Et je me rends compte qu'en effet, aujourd'hui, en regardant les profils en reconversion,
quand ils arrivent chez Fleet pour des stages, souvent,
ils ont beaucoup plus de mal parce que la plateforme, c'est complexifié.
Alors on peut toujours trouver des petits projets, les faire bosser un peu sur site vitrine pour commencer, pour se faire la main.
Sur des petits outils de back office qui vont être très indépendants du reste du système, etc.
Donc il y a quand même des portes, mais où il y a avant de 100% autonome sur un projet full JS, disons, peut-être que deux ans, c'est un chiffre.
J'aurais dit un peu moins.
Non, mais je prends le côté pessimiste du chiffre parce que,
parce que même moi, tu vois, Marc a été le premier employé, il a, en quelques mois, il a réussi à être autonome.
Mais encore une fois, je te dis sur un échantillon plus global ou derrière, on a essayé avec plusieurs autres.
Bon, alors c'est peut-être pessimisme, mais au-delà du chiffre en lui-même qui n'est pas très intéressant.
Ce que je retiens, c'est que, en tout cas, moi, mon sentiment, c'est qu'il y a toute une période d'adaptation et de faire grandir la personne.
Et ça, c'est très dur à intégrer et à gérer, je trouve, parce que la personne arrive avec des prétentions de marché.
Mais le marché, finalement, même s'il est un peu tendu, il s'est rendu compte que justement, il y avait ce coût de formation initiale à produire.
Et du coup, il ne se réunit plus vers des gens qui ont franchi ces deux ans.
Ce n'est pas pour rien que la vallée de la mort, c'est zéro en un deux ans.
Aujourd'hui, il y a un mur pour ces profils-là.
Aujourd'hui, il y a un vrai mur sur le marché visible.
Bien sûr.
Et moi, je me rends compte que ces profils, si je rate le runboarding, tu vois, je ne commence pas en leur disant, tu changes un wording sur une page,
puis tu changes une page statique, puis on va intégrer des éléments du design-system que tu comprends, qu'on fonctionne de design-system.
Puis on va te faire bosser son petit zéro et faire rentrer comme ça des petites mécaniques au fur et à mesure.
Oui, c'est hyper intéressant.
C'est que du coup, dans le management de cette personne, dans le runboarding, cette personne-là, tu vas vraiment granulariser la progression à fond.
Elle est fausse. Je ne l'ai pas faite.
Oui, j'ai vite regretté.
C'est dur de revenir en arrière sur ce genre de...
Depuis que tu es là-bas, tu as travaillé avec combien de personnes de ce profil-là qui sortaient de reconversion ?
J'ai envie de dire 6 ou 7.
6 ou 7 ? Et tu dirais que ça a été un succès, à quel ratio ?
7 et un succès à 60% du temps.
Ok.
C'est pas 6 ni par 7.
Non, mais je retiens des trucs un peu à la serre, donc 1 sur 2 à peu près.
Ok.
C'est quoi les tips que tu...
C'est quoi les patterns et les antipaternes pour réussir à intégrer ce genre de profil que tu as constaté ?
Oui, c'est ça. Prends le chose petit à petit.
Au niveau de l'entretien aussi,
essayer de déceler...
Voilà justement ce dont je parlais au début.
Est-ce que la personne a fait cette formation pour les bonnes raisons ?
Est-ce que c'est quelque chose qu'elle a envie de faire ou c'est parce qu'il y a une vision de ce métier qui n'est pas la bonne ?
Donc pendant l'entretien, je fais plusieurs tests.
Un test un peu de carré.
Alors du coup, ça fait des procès d'entretien un peu lourds,
mais ça c'est un peu la réalité du métier aujourd'hui,
que même quel que soit le niveau du dev,
j'ai l'impression que les procès sont de plus en plus lourds.
Donc un test pratique à faire chez soi,
sur lequel on revient ensemble, sur lequel je vais changer,
je vais poser des questions de design, etc.
On va aller un peu au-delà de...
J'ai utilisé un use state parce que je sais que c'est ça qu'il faut utiliser.
Ok, mais c'est fait quoi le use state ?
Si on a vraiment compris le fond du truc ou jusqu'où on a compris.
Je m'entends pas à ce que le type m'explique des chadodomes,
des trucs comme ça extrêmement complexes,
enfin par rapport au niveau demandé.
Ensuite, pareil, j'ai d'exercice un peu à tiroir,
ou en apparence, ça va être simple,
ça va être faire une boucle avec une condition à l'intérieur.
Donc itérée sur une phrase, etc.
Et ensuite dire, ok, c'est quoi ?
Combien de mémoires va prendre ce programme ?
Quelle complexité algorithmique ?
Et à pousser, pousser, pousser et voir jusqu'où ça peut aller.
Il va faire des choses où il y a un niveau zéro,
je vois si les bases sont liquides et après voir jusqu'où je peux aller.
Et du coup, c'est un filtre après pour toi ?
Ou c'est juste que tu s'attends après paraitre ton onboarding ?
En gros, est-ce que tu t'attends malgré tout
quand tu prends des profils en reconversion à avoir un bon niveau
ou tu sais que tu partiras de la base et c'est ok ?
Sur les problèmes de complexité algorithmique, etc.
Non, je m'attends pas à grand jour sur ces profils,
mais ça me permet de voir aussi
comment la personne va réagir au truc,
dire ok, je sais pas comment jamais scripter sa mémoire.
Tu vois, je veux dire, si ta phrase de base, elle prend un méga outil,
tu auras besoin de combien de mémoires pour faire ton programme.
Dire, ok, peut-être qu'il faut faire la somme des variables
pour avoir une idée de la mémoire prise par le truc.
C'est ce genre d'intuition qui va, à mon avis, refléter une connaissance,
alors déjà une connaissance d'une culture informatique de manière générale,
savoir ce que c'est de la mémoire, savoir ce que c'est de l'arabe,
savoir qu'en programme base, ça prend de l'arabe.
Alors, c'est des choses, en effet, on peut être passés à côté,
mais c'est plus un indicateur que vraiment go-no-go là-dessus.
Et pareil sur la question plus qualitative,
partir de choses simples, qu'est-ce que c'est qu'une API ?
Alors, je dis que c'est simple,
mais en vrai, personne ne sait vraiment ce que c'est une API.
Je sais pas si je te demande ce que c'est une API,
si tu auras la bonne définition.
Ah, c'est pas sûr.
Ça dépend déjà si tu parles d'une API d'une classe ou...
Je sais pas, je dirais que c'est le contrat de service livré par...
Ouais, pour moi, ça évoque ça, c'est un contrat de service en fait, une API.
Qu'est-ce que va faire ton objet ?
Qu'est-ce que va faire ton système ?
C'est très vaste.
Donc, en général, on va parler de...
Les gens vont vite décrire un API web,
je vais dire, ben, un API, ce n'est pas forcément web,
ça peut être entre ton processeur et ta carte graphique, tu as une API.
OK, c'est quelque chose qui prendrait que plein de données.
Je vais, ben, tourner en poule connecté,
il a une API qui est en voie de la lumière.
Bon, la lumière, est-ce que c'est une donnée, etc.
Donc, ça permet, tu vois, d'aller un peu plus loin.
Et d'après, voilà, sur les API REST, qu'est-ce que c'est ?
OK, qu'est-ce que c'est le protocole HTTP ?
Et donc, c'est des questions assez générales,
mais qui peuvent être très foisonnantes.
Et ça, ça me donne une certaine...
Une assez bonne vision, à mon avis, de...
On va dire, la culture tech de la personne,
enfin, je sais pas trop comment appeler ça.
Non, mais ça, culture tech, je pense que c'est une bonne définition.
Mais après, du coup, comment tu fonctionnes ensuite
pour te dire go no go ?
Alors, c'est quoi tes critères ?
Parce que tout ça, ce sont des choses qui vont...
Encore une fois, quand tu sors d'une formation courte,
je suis pas bien certain que tu aies beaucoup eu de considération
sur l'empreinte lémore,
que tu aies beaucoup de considération sur vraiment les couches
ou de base de ton système ou même sur l'album.
C'est la manière de réagir à la question
que la réponse en elle, même, qui va être intéressante.
Et ça, ça devient un critère pour toi.
En gros, est-ce que la personne fait preuve de quoi ?
C'est quoi les qualités que tu vas chercher ?
Alors, ça va être la curiosité, la volonté d'aller chercher quelque chose
ou de dire directement, je sais pas.
Si la personne, je pose la question.
Alors après, ce qui est compliqué en entretien,
c'est qu'il y a forcément le facteur de stress.
Il y a des gens qui peuvent parler de leur moyen aussi.
Oui, c'est pas dans une...
C'est pas en train de discuter le gras autour d'un café,
quoi, c'est...
Bien sûr.
Il y a de l'enjeu, en fait.
Ouais, c'est un peu voir la réflexion de la personne,
c'est la manière de réfléchir.
Comment quantifier ça ?
Donc, tu fais au feeling, en fait.
Au final, une filet, tu fais au feeling, en fait.
Au final, c'est au feeling, mais ça, je pense,
c'est un peu pour tout le monde.
Alors, on a essayé différents systèmes de notation,
mais il y a des nogo que tu vas avoir directement.
Et le plus dur, bien sûr, c'est les mayby.
Et on est toujours en recrutement quand c'est mayby.
C'est que c'est pas bon.
C'est ça, préfère...
Quand il y a de doutes, c'est...
Quand il y a de doutes, il y a pas de doutes.
Et franchement, oui, des trucs où le gars,
au bout de cinq minutes, tu sais que tu es tombé amoureux,
que tu as envie de leur recruter, ça t'arrive, des fois ?
Ouais.
Ouais, ça m'est arrivé, ça m'est arrivé.
Ça m'est arrivé plusieurs fois et...
Pour l'instant, je me suis pas trompé.
Je fais quand même l'entretien en entretier pour valider.
Mais en général, quand c'est oui, c'est...
Moi, je me rappelle d'un entretien avec le second...
Le second template de la boîte qui s'appelait Beno aussi,
qui...
Le moment où ça a basculé, dans ma tête, je me suis dit,
ok, tu vois, pourtant, il y a pas de loin de dix ans,
donc c'est que ça m'a marqué, on discutait,
il nous montre un petit peu ce qu'il avait fait,
et puis je lui dis, si tu dois prendre en main
une nouvelle brique logicielle que tu connais pas,
il n'y a pas la doc, comment tu t'y prends ?
Là, il nous a regardé, je l'ai le code.
Pour lui, le manuel, c'était le code, quoi.
Et là, je me suis dit, ah oui !
Toi, je veux travailler avec toi.
En tout cas, c'est ce genre de...
Ça m'avait bien plus comme réponse.
Ok, donc toi, finalement, j'entends une bonne...
Une bonne expérience, finalement,
avec les gens en conversion,
avec ces profils de reconversion.
Tu dirais que si on a une...
Ouais, tu dis même, la personne peut commencer à contribuer,
finalement, au bout de quelques semaines, quelques mois,
même quelques semaines, t'as dit,
à condition que, finalement,
qu'on lui adapte la difficulté de ce qu'il a à faire.
C'est ça.
J'ai l'image d'un truc qui mange beaucoup de temps, en fait.
Oui, je pense que je suis pas optimale là-dessus.
Et puis, je suis en seul manager avec une équipe de 5 devs.
Là, aujourd'hui, on a 3 CDI, on a eternal un stagiaire.
Donc, c'est avec le stagiaire que je prends le plus de temps, forcément.
Parce que le devs, c'est une discipline, on dirait, cumulative.
Il y a toujours des...
Quand on recrute quelqu'un de nouveau, on reprend de zéro.
C'est pas comme d'autres métiers où on a construit des choses,
et la personne qui arrive en sur-à-ce-poste,
elle va reconstruire sous ce qui a été construit.
On parle de zéro en termes de connaissance.
Je sais pas si c'est que...
En termes de connaissance métier, oui.
Après, j'espère pour lui, qu'il remporte son bagage technique.
Non, bien sûr.
Mais de mon point de vue, du point de vue de l'entreprise,
on reprend la formation de zéro.
Surtout sur des profils en reconversion, ça, c'est sûr.
Nous voilà aujourd'hui, on essaie quand même de capitaliser sur les talents,
mais forcément, on a encore un peu de ces profils.
J'avoue qu'au début, de moins de l'aventure,
c'était des profils qu'on comprenait très volontiers,
parce que d'abord, on n'était personne,
et il faut qu'il y ait des gens qui te fassent confiance.
Voilà, il faut avoir un côté sexy.
Au moins tout seul, je lançais mon petit cabinet,
je n'étais pas spécialement sexy.
Donc ça a été une manière aussi, un peu comme tu l'as dit,
de faire appel à des gens qui vont te coûter peut-être un petit peu moins cher.
Ce que j'ai trouvé vraiment cool,
c'est que ça donnait une opportunité, une chance à quelqu'un de se déployer.
Mais c'est vrai qu'avec le temps, j'ai remarqué que tout le monde ne s'asistait pas,
cette chance, et du coup, ça consommait beaucoup d'énergie de l'entreprise.
Et nous, on avait un modèle très particulier,
enfin particulier, non pas très particulier,
très commun, mais qui est celui d'une ESN,
où, si tu veux, il y a une logique aroïste sur le temps qui est extrêmement forte,
tu es payé à l'heure,
ou alors que ce soit le format forfait ou régime,
ça va être un peu pareil.
Et du coup, nous, on avait vraiment un problème pour financer ça, en fait.
Pour financer cette montée en compétence, dans le modèle,
moi, je n'y arrivais pas.
J'arrivais pas à vendre assez cher mes prestations
pour avoir la marge de prendre un autre charge quelqu'un.
Et au-delà du coup, direct d'aller à la personne,
il y avait le coup indirect,
c'est que quand un des devs s'occupait de lui, il ne produisait pas, en fait.
Bien sûr.
Oui, le temps de recrutement...
Le temps d'encadrement, de formation, d'aide.
Si ça ne fonctionnait pas.
C'était...
Bon, l'équation, elle ne marchait pas toujours, voire rarement.
Et du coup, à un moment donné, c'est vrai que...
On s'est dit, finalement, on marche bien à trois, on continue à trois camps.
Et le quatrième, la ron qui nous a rejoint,
j'ai attendu d'avoir plus de moyens pour recruter quelqu'un déjà de compétent, en fait.
Bien sûr.
Je pense que c'est plus efficace d'être avec une petite équipe
qui connaît bien le produit, qui peut faire confiance,
que d'essayer d'avoir une grande équipe où tu vas avoir plus de chance,
si je lui permets de...
De personnes à renouveler dans l'équipe, où il faut reformer,
où il y a du risque si le recrutement n'a pas été bien fait, etc.
Mais chez un éditeur, je pense qu'on peut raisonner différemment,
parce qu'un éditeur peut se permettre...
Alors pas, je ne dis pas de cramer de l'argent,
mais peut-être peut se permettre un peu plus d'investir,
parce qu'un éditeur va avoir une vision plus long terme, en fait, je pense.
Alors que nous, les projets, ils étaient sur quelques semaines, quelques mois,
et le projet était fini, le client avait passé autre chose.
Bien sûr.
Et je ne sais pas si c'est le cas pour toi aussi,
mais j'ai l'impression que le marché,
il y avait énormément, dans le marché de recrutement de dev,
a énormément changé depuis la pandémie.
Oui, clairement.
Et comment tu le vois, toi, dans quel sens, tu le vois ?
Alors, comme j'ai fait beaucoup d'entretien avec des gens en reconversion,
il y a beaucoup de gens qui sont...
Pour qui ils se sont dit que c'était le bon moment pour changer le métier,
alors soit parce que leur boîte a coulé, simplement,
soit parce qu'on a eu le temps de se remettre en question, etc.
et qu'ils avaient plus de temps libre,
qu'ils sont lancés dans des formations à côté de leur boulot,
que ça leur a plu, ils ont pris une formation plus longue.
Et donc, ça a contribué un peu à cette saturation de marché,
où il y a plein de gens qui veulent être dev,
peu de gens qui arrivent bien à être dev,
et aujourd'hui, en plus, avec la conjoncture économique,
un marché qui est en...
Surtout moi, je vois, je suis dans...
nos clients sont des startups, on est une startup.
Ça a été compte, il y a beaucoup moins de levées de fonds,
beaucoup moins de recrutement chez les startups qui,
elles ont levé des fonds qui veulent économiser un peu leur cash,
parce qu'ils ne sont pas sûrs de pouvoir relever dans les mois à venir.
Le grosse contraction du marché à ce niveau-là,
qui fait que le recrutement devient de plus en plus compliqué,
donc de plus en plus de gens moins qualifiés,
de moins en moins de gens qui veulent recruter d'autre part.
C'est les échos que j'ai eu, ouais.
C'est les échos que j'ai eu, que la pandémie avait...
alors pendant ça allait, parce qu'on a...
les TechJones ont pris...
ils avaient la cote, forcément.
Mais le contre-coup de ça, c'est que les capitaux sont en train de bouger,
il y a une espèce de contre-coup, une espèce de gueule de bois du lendemain,
où d'ailleurs tu le vois sur les cours de bourse,
c'est géant qu'il y avait pris,
qui cross-valent à recracher.
Ouais, non, ouais, un peu en rotor de face, je lui dis.
Du coup, j'ai un peu ce son de cloche,
que effectivement, des gens continuent à se former,
alors que le marché avait déjà du mal à absorber ces profils-là.
J'imagine qu'il y a d'autres boîtes,
d'autres formations qui ont dû émerger en plus,
donc t'as assez popularisé d'autres en plus.
Et donc je sais que c'est très dur aujourd'hui pour les reconvertis,
trouver un taf, c'est très, très, très, très, très, très dur.
Oui, justement, il y avait une personne suite à une reconversion
qui avait fait une formation courte, qui avait fait un stage de six mois chez nous.
Alors déjà, quand t'as 30 ans passé de payer ta formation,
puis y a-t-il six mois en stage, un salaire de stagiaire,
et après se retrouver six mois au chômage, c'est...
Non, c'est pas évident, c'est pas évident.
Alors je ne veux pas décourager tous les gens qui se lancent dans ce genre de formation,
mais c'est la réalité du marché aujourd'hui.
Je sais qu'ils ne peuvent pas forcément...
Moi, le conseil que je donne aux gens qui veulent se lancer là-dedans,
c'est, et tu dis vraiment ta finance,
est-ce que tu es capable d'encaisser deux ans,
je reviens sur mes deux ans,
est-ce que tu es capable d'encaisser deux ans
ou tu ne trouveras pas de travail en fait ?
Parce que si tu es capable,
je suis certain que si tu bosse tous les jours que tu fais,
tu travailles sur un projet perso, que tu développes un truc,
que tu fais un projet, que tu fais quelque chose vraiment tous les jours
et que tu travailles,
je suis sûr qu'au bout d'un moment, tu finis par trouver un travail.
Parce que tu as franchi cette espèce de valet de la mort des euros,
zéro à un an,
mais en travaillant sur ton propre projet.
Mais si jamais quelqu'un n'est pas capable,
et je pense que, enfin moi, je suis pas capable de tenir plus de deux,
trois mois sans argent, enfin, sans un pas, après,
il vaut peut-être mieux pas se lancer là-dedans, quoi.
Ouais, et c'est dommage parce que moi, quand je me suis mis au dépe,
j'étais adobre, la première fois que je suis internet,
je me dis que c'est génial n'importe qui peut mettre sa page sur internet.
J'ai ouvert Notepad et j'ai écrit Hello World et je l'ai mis sur FTP.
Et tout le monde pouvait le voir.
C'est un truc de ouah.
Et donc je comprends ces gens qui disent, c'est génial, je veux faire ça.
Et qui se retrouvent face à ce mur,
ils disent qu'il y a plein de formations,
il y a plein de boîtes qui recrutent et qu'ils se retrouvent à l'air à été du marché.
Aujourd'hui, ce qui peut être un peu décourageant.
Il faut tenir.
Non, mais en tout cas, dans notre échange,
je me réconcilie avec ça parce que je t'avoue que j'étais devenu un peu
dubitatif, mais de voir des cas où ça marche bien,
où tu arrives à en faire ta modalité RH et où tu dis,
bah voilà, en mettant de l'huile de coude, en découpant bien les choses
et en accompagnant bien les gens.
Oui, c'est possible.
Bah écoute, ravis.
Alors, je suis très content.
Il faut faire pas mal de tri quand même,
parce que comme je disais, comme la barrière à entrée est plus faible,
alors ça reste de l'argent, mais du coup, c'est plus accessible à des professeurs.
Pour un que tu prends, tu dirais qu'il faut combien de,
tu passes combien d'entretien pour un que tu prends ?
Je pense que c'est pas d'user ce qu'on fait.
Alors, au genre, même si on n'a pas que des personnes en reconversion dans le pipe,
il n'y en a quand même pas mal parce que c'est aussi ce qu'il y a sur le marché,
finalement, quand tu mets une offre, il y a beaucoup de professeurs encore.
C'est de CV de profil en reconversion.
Je pense que des premiers calls, on en fait 15-20 peut-être pour un recrutement.
C'est ça, tu prends 15-20 lead entrant, c'est-à-dire 15-20 personnes.
Et sur ces 15-20, au fur et à mesure du processus, tu vas arriver à une.
C'est ça.
L'idée, c'est de passer plus de temps, de funnel qu'en début, je vais en dire.
Et donc au début, on fait un premier call
parce qu'avec une personne technique, parce que les devs n'aiment pas parler au RH.
Alors ça, c'est un sujet à part entière.
Mais moi, avant, je faisais moi, maintenant, c'est une des devs qui je bosse,
qui fait ce premier call pour savoir sur quelle technique nous avons bosse,
comment on bosse, la méthodologie, etc.
Ce sont des trucs qui sont bien d'avoir au premier call.
Il ne vaut mieux pas que ce soit un RH qui les explique.
C'est ça.
Je crois que c'est du Java ou du JavaScript, je ne sais plus.
Et voilà.
Et donc ce premier call, après, on envoie directement un exercice à faire chez soi
pour faire ce premier fill qui nous demande le moins d'efforts possible.
Alors ça demande beaucoup d'efforts de la part des candidats,
mais du coup, ceux qui sont moins motivés ne le font pas.
Ouais, c'est un autre filtre.
Bien sûr.
Alors je fais un retour à 100% des exercices que je reçois.
Je pense que c'est super important aussi, ce que la personne passe
souvent plus de temps que ce qu'on lui demande.
C'est-à-dire que c'est quelque chose passe une heure, deux heures max dessus.
T'es stressé, t'as envie d'avoir le boulot, tu vas passer quatre jours dessus.
Je comprends entièrement.
Je vais essayer de juger un peu sans prendre en compte le temps passé.
De toute façon, ça se voit directement si quelqu'un a passé une semaine
ou si quelqu'un a passé une demi-heure.
Ah ouais ? Tu le vois à quoi ?
Peut-être pas directement, mais...
Alors déjà, je demande de mettre le truc sur GitHub,
donc on voit s'il y a 12 comites.
D'accord, ouais, tu vas les comites, tu vas les d'autres.
Alors ça ne veut pas forcément dire.
Des gros choses.
Cousser du copier collé de code, les variables ont pas les bons noms, etc.
Parce que c'est quand même un exercice assez standard qu'on fait faire.
OK.
Ouais, il y a des petits râtes flacques comme ça.
Donc je fais toujours un retour là-dessus.
Et donc après, en général, on a déjà...
On va dire, on va passer la plupart des gens à entretien physique.
Pareil, comme il y a l'effort qui a été fait sur l'exercice,
même si ce n'est pas parfait.
Et re-changer cet exercice pendant l'entretien physique.
Parce que c'est bien de discuter sur du code.
C'est un truc super important de voir comment la personne réfléchit.
Il y a aussi un peu les pages sagesques l'antidestin
qui ont trouvé un repository qui faisait exactement ce qu'on vous voulait.
Ou c'est le cousin qui est d'avec depuis 10 ans qui a fait exercice pour lui.
C'est ça du coup, on le détecte vite en parlant du code.
Et voilà, en fait, ce premier filtre, il va filtrer déjà pas mal de gens.
Et on va avoir les 8-10 entretiens physiques pour un recrutement.
Je pense qu'on est assez standard là-dessus.
OK, intéressant.
Bon, c'était notre premier sujet.
Est-ce que tu as encore des trucs que tu as envie de dire sur le recrutement?
Je pense qu'on peut en parler des heures, mais là, rien ne va nous faire la tête.
Tu m'avais proposé de parler du mise en place et du maintien d'un design système.
Vu que j'ai eu l'occasion d'interviewer deux boîtes,
je suis curieux aussi de voir un peu comment sur le sujet.
Comment est-ce que vous avez mis ça en place?
Qu'est-ce que ça vous apporte au quotidien?
Est-ce que c'est un vrai garde-fou quand on a des gens typiquement
qui sont en reconversion qui vont peut-être avoir besoin d'un peu plus de cadre?
Alors, on a commencé en disant, en prévention du site,
tu as été assuré un libre-aid composant,
on va dire un design-system existant qui s'appelle Bloomer, qui est déprécié maintenant.
Donc, c'est un peu un équivalent de matériel,
mais en un peu moins développé, on va dire.
Donc, on a voulu sévoyer cette libre-aid composante.
Donc, ce qui vient logiquement, c'est de faire notre propre libre-aid composant.
On s'est dit, soit on fait tout de suite ce 150 composants,
on a un truc complet, ça va être super,
et ça va prendre deux mois de dev, on est deux personnes dans l'équipe,
on n'a pas le temps de faire ça.
Donc, on va essayer de faire un truc un peu progressif.
On va faire d'abord le composant input,
parce que c'est un truc qu'on utilise sur tous les formuleurs,
qui est un peu partout.
À chaque fois, il a une gueule un peu différente,
c'est bien de bien y formiser, etc.
Donc, on a fait notre composant input,
c'était notre design-système avec un composant qui s'appelle input,
c'est un composant qui s'appelait bouton, sans doute.
Et quand il est devenu tant d'itérés sur ce design-système,
on n'avait pas la ressource, on n'avait pas avant de passant,
donc on est resté, allez, six mois avec ce design-système de deux composants,
et tout le reste, c'était pas unifié.
Donc, c'était un peu un échec, ça avait pris pas mal de temps,
on avait bossé avec le designer pour faire ça, etc.
Alors, je caricare-t-il un peu, on est sans doute plus de deux composants,
mais c'était pas non plus un truc très complet.
Il y avait au cours des endroits du dôme de code,
on utilisait l'ancien libraï, etc.
Pourquoi tu dis que c'était un échec, si c'était utilisé ?
Euh... Non, t'as raison.
Alors, parce qu'on est en ce moment.
Non, mais c'est intéressant, c'est-à-dire que tu le vivais comme un échec,
peut-être parce que tu n'arrivais pas à le faire vivre comme tu voulais ?
Alors, on avait passé beaucoup de temps, en fait, dessus,
c'est plutôt dans ce sens-là où il y a une dev,
un designer qui avait passé sans doute un mois dessus,
donc pour designer en effet six composants, ça fait beaucoup.
Alors, bien sûr, avec tout le reste du boulot,
en fond, c'était peut-être pas du 100%,
mais il y avait quand même pas mal de temps dédié dessus.
Et c'est une première brique.
Alors, et je dis aussi que c'est un échec,
parce que finalement, ce qui a mieux fonctionné, c'est ce qu'on a fait après.
Donc, comme je vous disais, on n'est pas une grosse boîte,
donc avec un moment, on a voulu faire une refonte entière de notre plateforme,
donc de gestion de flotte.
Et on a fait appel à un design studio.
Et donc, eux, ils avaient cette expérience que nous,
on n'avait pas de faire un design un peu unifié,
et de dire, on va travailler en Atomic Design,
donc on va définir nos composants,
définir nos atomes, nos molécules, nos systèmes,
faire tout ça de manière unifiée,
et faire toutes les maquettes Figma à partir de ça,
donc avoir les composants d'en Figma qui vont emporter dans chaque maquette, etc.
Et à partir du moment où on refusait un gros design comme ça,
From scratch, carré où le design était cohérent avec le design,
alors les maquettes étaient cohérentes avec le design système,
il fallait que le dev soit cohérent.
Il fallait la ligne, c'était quand même vachement plus simple d'aller vers ça.
Et donc là, cette fois-là, vous avez réussi à en brancher,
ce que je comprends, c'est que du coup, à partir de là,
parce qu'on a réussi à justifier aussi côté business,
le fait de redesigner entièrement la plateforme,
de repartir from scratch,
quasiment,
surtout l'interface pour la professionnaliser, la moderniser, etc.
C'était vraiment le bon moment de le faire.
Et là, on a fait, j'allais dire, un vrai design système,
donc on avait une vraie libération de composants assez complète,
et comme c'était de rêver par design, je pense que ça a beaucoup aidé,
vers ce savant où c'était plus rêver par le dev,
donc il y avait un nouveau designer qui arrivait en stage,
qui savait pas qu'il y avait une ébrouille de composants,
qui faisait un petit rectangle pour faire ses inputs.
Donc voilà, là, on avait la libération de composants côté design,
un outil qui s'appelle Zeroite,
je ne sais pas si c'est quelque chose avec une coitée familier.
Non, vas-y décris-nous.
En gros, c'est une interface à tes composants Figma,
ça te fait une petite vue web,
avec ta liste de composants, différents cas de design,
et le personnage de différents composants.
Et l'équivalent Dev, c'est un outil qui s'appelle Storybook,
donc il permet pour chacun tes composants
de créer un fichier pointstory.js,
qui va mettre en scène ce composant,
et pareil, tu crées toute une interface web autour,
avec possibilité de changer les différentes propriétés de ce composant,
donc dire, je veux la variante secondaire du composant,
ça va t'appuyer vers une secondaire.
C'est deux éléments qui faisaient un peu sur l'office de référence,
le Zeroite d'un côté, et le Storybook de l'autre.
Voilà, on a des arguments tôt et tôt pour dire,
tout ce qui apparaît dans le code,
ça va correspondre à ce Storybook,
tout ce qui apparaît dans le Figma,
ça va correspondre à ce Zeroite.
Je n'ai pas encore craqué la manière de dire
le composant qu'on a designé dans Figma,
Figma génère-moi du code React avec,
ça n'est pas encore trouvé sur le bouton,
j'ai essayé plusieurs systèmes,
mais je pense qu'il y a un peu trop de complexité,
c'est dommager, je pense qu'il serait assez pratique.
Finalement, ce que je retiens de ce que t'as dit,
c'est que l'approche où on essaye d'aller en progressif,
visiblement, ça n'a pas super bien marché,
en plus de la dév, tu dis,
le moment où ça a marché pour vous,
c'est le moment où il y a eu une grosse remise à plat,
finalement un roi d'émarrage,
et que ça a été plutôt dirigé par le design.
C'est ça, je peux faire un parallèle aussi avec
les tests et process-quadités,
c'est dire, on va écrire des tests
un peu au fil de l'eau, fur à mesure,
alors ça marche un peu,
mais ce qui marche mieux,
c'est de, non, ça marche pas,
tout petit peu,
ce qui marche, c'est dire, soit, ok,
on fait une grosse session,
on essaie d'atteindre une code coverage
sur ce quartier de 90%,
il y a des sprints vraiment dédiés à écrire des tests,
alors, idéalement, parce que nous on a du retard
sur ce fait que tu as des tests, idéalement tu fais du TDD,
par exemple, on peut en parler,
et tu écris tes tests avant d'écrire ton code,
et tout est testé avant d'être même
développé,
mais quand tu es sur une base de code
qui n'y a pas une bonne couverture de code,
dire, on va faire les tests de quoi à mesure,
ça ne s'impasse pas trop, je pense
c'est un parallèle pas trop mauvais.
T'as l'air convaincu,
en tout cas t'as l'air pensé que le TDD
est une bonne pratique, et tu dis que
dans le visibilement, ça n'a pas toujours été répondu,
c'est pas forcément répondu,
vous en êtes où ça de l'adoption du TDD en interne ?
Non, je ne dis pas ça,
je sais que c'est un peu remis en question maintenant.
C'est ce que j'ai compris en fait ?
Non, je dis que c'est peut-être un idéal
ça a été recommandé à ce point,
non je ne suis pas forcément
partisan du TDD,
alors déjà on en fait pas,
c'est plutôt signe que...
parce que aussi on avait...
sur le testing, alors là on arrive sur un autre sujet,
on peut passer là-dessus,
c'est pas la question sur le...
Non, sur le TDD,
ça va, c'est cool.
Sur le TDD,
alors pareil, comme je disais, au début j'étais tout seul à sa plateforme,
donc je dis bon, on va y tirer vite,
on sent une première version en mars,
une deuxième version en avril, une troisième version en mai,
donc on écrit pas de tests, on verra plus tard les tests.
Alors souvent plus tard c'est jamais,
donc on a mis pas mal de temps
avant de mettre en place nos premiers tests,
et pareil,
en restant sur des petits équipes
ou des projets où on veut délivre rapidement,
alors on n'est pas sur un métier
où il y a du gros risque,
on va dire, comme du banking,
ou de la santé, etc.
où là si tu as un bug, ça peut être catastrophique.
Donc moi j'essaie d'avoir
une vision un peu...
comme on dit,
d'avoir un risque calculé.
Je sais qu'il y a un risque dans ce moment en ligne,
je sais où il est,
et voilà,
donc c'est de limiter ce risque.
Ok, donc quand je t'écoute, j'ai l'impression qu'en fait tu dis
on avait besoin d'aller vite tout ça,
donc ça veut dire que
en fait déjà, j'ai l'impression que tu ne peux pas
les délivrer aux créatures de tests,
comme un générateur de surcoût,
et en plus tu dis on est sur
une notion de risque calculé, donc là on est
encore une fois dans une vision
du test qui est une vision
d'assurance qualité, c'est
de vérifier que ça marche, nous prémunis
d'un problème.
Ce qui est une vision, mais
là où ça me gêne de mélanger ça avec du TDD,
c'est que
pour moi je fais du TDD
pour aucune de ces raisons en fait.
En fait quand je fais du TDD
je suis plus efficace dès la première seconde,
donc non seulement
je ne le perçois pas comme un surcoût, mais je le perçois
comme un facteur de compétitivité
au contraire.
Et ensuite en termes de, je ne fais pas du TDD
parce que ça réduit mon risque.
Je fais du TDD parce que c'est
ma manière de concevoir mon code et d'aller vite
en fait, de travailler plus efficacement.
Et ça a eu l'effet, il se trouve que ça produit
du code plus robuste, et ça a eu
l'effet qui n'est pas négligeable, tu vois.
Et tu vois, voilà, après
depuis que je suis passé à la blockchain
j'écris parfois des tests,
j'allais dire qu'ils servent à rien, ils sont intéressants
ils servent à rien du point de vue du TDD
parce que je fais du verre sur du verre, mais
mais ils sont
utiles parce qu'ils sont là dans une logique
d'assurance qualité, les enjeux sont tellement critiques
quand tu écris du code
que tu ne seras pas modifié, qu'il va brasser
peut-être 1, 2, 3 millions d'euros
tu as envie d'être serein sur le fait que
que ça va quand même marcher
et qu'il y a des cas d'usage
un peu aux entournures
que tu veux contrôler
et t'assurer que ça fonctionne. Donc je fais
parfois du test after, mais
tu vois, je fais du TDD
pour aucune des raisons que tu veux à qu'en fait.
Non, je comprends. Alors
je ne suis pas expert
en TDD
j'en ai sans doute pas assez fait
et je dois être sans doute en faire plus
après il y a un peu le coût de mise en place
justement du TDD
qui est peut-être un peu plus...
Alors le coût de mise en place c'est
2 minutes 30 à peu près le temps de télécharger
un JUnit ou je ne sais pas
ou un Chai en est sur Nod
mais par contre
le temps d'apprendre
à le faire, oui ça ça prend du temps
on est d'accord. Enfin ça prend de l'énergie
ça prend de l'énergie et
de zéro à compétence sur ça
je pense qu'il faut
plusieurs semaines à plusieurs mois selon le niveau
d'énergie que tu peux y consacrer et d'encadrement
que tu peux avoir à recevoir dessus.
Et ça va un peu avec ce que je disais
d'essayer de simplifier au plus possible
ma plateforme
quand je parle de la plateforme
ça va être la plateforme de code on va dire
pour justement avoir le plus
faible coût à l'entrée
pour ces recrutements le premier sujet dont on parlait
qui se fasse
le plus simplement possible
toi si j'ai une personne de formation courte qui arrive
je lui ai dit alors c'est du TypeScript
t'en as jamais fait et c'est du TDD
t'en as jamais fait j'aurai plus de problèmes
Je ne sais pas parce que
parce que le TDD
si tu l'enseignes
et si tu l'utilises
en fait je me rends compte que ça
pose
pour des gens qui découvrent un petit peu
quand tu entends quelqu'un dans une culture déjà forte
c'est pas
ouf
ça demande de l'énergie c'est sûr
ça demande de former la personne c'est certain
et tu as raison ça lui a emmené une couche de plus
mais ça peut très bien s'intégrer dans la pédagogie
si c'est naturel pour toi ça sera naturel pour lui
et même au contraire
le TDD t'amène
un code qui est encore plus simple
en général quand tu conçois
en TDD
moi j'ai remarqué que j'écrivais moins de code
que je l'écrivais de manière plus affûtée
beaucoup plus juste
donc tu simplifies en général pas mal ton
système
et en plus
là pour le coup tu as un garde fou
qui est hyper appréciable
tu sais que si tu passes tous les tests
a priori c'est que tu n'es rien cassé
donc c'est hyper aidant pour quelqu'un qui arrive sur un projet
d'avoir une couverture
à 99% parce que tu sais que
tu as peu de chance d'avoir cassé quelque chose
je suis pas en train d'essayer de te vendre le truc
non mais justement
dans ta situation
je me suis dit que c'était une pratique au contraire
hyper aidant
j'ai peut-être été par le passé un peu dogmatique
sur le TDD en me disant
ça prend du temps et finalement
il y a quand même des bugs qui passent au travers
mais je te promets
de donner une nouvelle chance au TDD
yes
une victoire
une chance j'ai dit pas
non mais moi c'est
ma victoire après que tu le mettes en upropeage
j'ai envie de te dire c'est ton problème
mais là où j'ai une victoire
c'est d'avoir fait bouger
et puis surtout pour toi qui écoute
et qui a bougé je sais pas combien d'auditeurs
que ça va questionner parce que
les arguments que tient c'est ce qu'on entend tout le temps
en fait
donc en la matière
de répéter
parfois pour enfoncer un coup faut taper
plusieurs fois dessus
ça fait pas de mal et puis il y a peut-être des gens qui écouteront cet épisode
et qui se diront que c'est
un truc qu'ils ont très envie de faire écouter
à leur collaborateur
et ce sera l'occasion d'un épisode partagé
donc
être sûr de la vertu à revenir sur ces fondamentaux
un truc que j'ai remarqué
en me tend en place des tests
alors pareil je pense que c'est
les choses qui s'effacent en ayant une meilleure couverture
de ces tests en étant plus rigolo sur ces tests
c'est que
comme on dit
il y a
le fait que les tests
j'ai des devs qui vont dire
c'est bon de toute façon si il y a des bugs les tests les attrapons
donc on a une perte
de vigilance du fait qu'il y a des tests qui sont derrière
et dire
les tests passent c'est que mon code
est bon
carrément mais c'est pas une question
c'est rigolo tu vois encore une manière de voir les choses
c'est pas une baisse de vigilance
c'est que tu
éteins complètement ce truc là
et du coup
là où j'ai l'impression que toi tu le vis
tu le perçoies comme quelque chose de
peut-être un facteur de risque ou quelque chose qui n'est pas bien
mais au contraire le fait de pouvoir te concentrer
uniquement sur ce que tu es en train de faire
et tu sais sans t'aider avant je me rappelle
avant j'avais une espèce de cartographie mentale
de tout mon système
ça demande une énergie mais colossale
à ton cerveau en fait d'avoir
en permanence tout ton système en tête
de réfléchir à tous les impacts
que tu vas pouvoir avoir
est-ce que je suis pas en train de faire une connerie est-ce que je suis pas en train de casser un truc
toi je revis des moments de stress
là j'ai tout mon estomac il est déjà en train de se
recontracter là pendant que je repense à ces moments-là
parce que
littéralement je vivais dans la peur permanente de casser un truc
avec les tests
je n'ai plus un souci de ça en fait
si c'est vert c'est que c'est bon
et donc mon esprit peut
tu vois je libère un max de RAM
et 100% de mon cpu
il dédié à la tâche que je suis en train de faire là ici et maintenant
mais dans ce cas tu as besoin que ton test
couvre 100% des cas d'usage
est-ce que les tests peuvent couvrir 100% des cas d'usage
bah si tu bosse en t'aider
c'est un
c'est
comment dire c'est natif tu vois
la couverture à 100% quand tu bosse
en t'aider c'est juste normal en fait
ce qui est anormal c'est quand t'es en dessous
parce que dans le processus tu es obligé
de
d'écrire un test rouge avant donc
il y a forcément le test qui va couvrir
le morceau de code que tu es en train d'écrire
si c'est pas le cas c'est que tu as écrit trop de code
auquel cas tu peux, attention je ne suis pas en train
de dire que t'es aidé de te garantir quoi que ce soit
comme tu l'as dit malmis en œuvre
c'est comme tout il n'y a pas de magie
mais l'outil est tellement simple
tu crées un test qui ne marche pas et tu le fais passer
et tu refactors
tu vois c'est un enfant ta
mais le mettre en œuvre t'amène ça
et donc oui de base
la plupart des projets sur lesquels on était
on n'était pas à 100%
toujours des cas un peu chiants en limite
notamment les cas d'erreur qui sont pourtant ceux les plus intéressants
à tester mais je reconnais que
j'étais plutôt dans la zone des 98%
sur certains projets
on se fixait
quand on sentait que le projet
était peut-être un petit peu plus gros avec plus en jeu
on se fixait une règle simple
alors pas forcément le 100%
mais la règle qui a le mieux marché
c'est tu n'as pas le droit de baisser le coverage
d'accord
et donc forcément
tu as obligé d'inclure une espèce de courbe tendentielle
ou tu augmentes donc je vais le souvenir d'un projet
où on avait dû démarrer cette règle à 95%
à 96% et au bout de quelques temps on était à 98%
tu vois mais le truc voilà
t'as pas le droit de baisser la et ça te donne
des trucs très drôles hein ça donne des trucs
parce que comme tu as réfléchi en termes de proportion
parfois ça veut dire que tu vas aller
chercher à supprimer du code pour jouer
sur les ratios des trucs comme ça
c'est un peu sux mais voilà
mais du coup aller chercher le dead code aussi
exactement
donc tout ça c'était quand même bon
finalement pour le code
on jouait un peu, on trichait un peu
on te rendait un peu trop dur parfois
mais c'était quand même bon pour la base de code
alors oui tu as raison
si tu t'amuses pas à avancer
tu vas pas conduire sur l'autoroute
à 140° les yeux fermés
donc oui il faut que tu aies des batteries test
mais si tu l'as démarré en t'aider
tu les as en fait
et si tu l'as pas démarré en t'aider
ça veut dire qu'il faut progressivement y aller
et je t'invite vraiment à faire cette expérience
et de te rendre compte
que justement tu peux poser
au contraire toutes ces préoccupations que tu as
de est-ce que ça va pas clasher
pour partir sur ça
ça marche
on arrive à la fin de notre boîte de temps
c'était super d'échanger avec toi
est-ce que tu peux nous dire si les auditeurs veulent en savoir plus
ou est-ce qu'ils peuvent te retrouver
alors
sur mes réseaux sociaux
sur LinkedIn
Benjamin Brezzy
ou sur Twitter
et donc je travaille chez Fleet
Fleet.co
merci Benjamin
quand t'as toi cher auditeur
écoute la perche est trop bien tentée
si tu es en envie de découvrir le craft
de savoir un petit peu ce que c'est
il y a un super article sur le podcast
sur le blog artisandeveloper.fr
tu verras il y a tout un article sur le craft
et bah écoute je te remercie de ton attention
et je te dis à bientôt