Bienvenue sur le podcast Artisan Developer, l'émission pour les programmeurs qui veulent
vivre une carrière épanouissante.
Prêts à passer au niveau supérieur ? C'est parti !
Aujourd'hui je suis avec Pierre Clinulancy, Pierre bonjour.
Salut.
Enchanté, est-ce que tu peux te présenter en quelques mots pour ceux qui ne te connaîtraient
pas sur le podcast ?
Je ne sais pas fait.
Alors, Pierre Clinulancy, comme tu l'as dit, je suis maintenant, je me décris plutôt
comme coach et consultant dans le milieu des tests unitaires, des cleanarchies, etc.
front et back.
Et je suis présent maintenant sur LinkedIn depuis un peu plus de deux ans, donc si vous
vous connaissez ces probablement à travers LinkedIn, je suis frivence depuis plus de
12 ans maintenant, ça commence à faire, j'ai jamais été salarié.
Et en parallèle, je prévois tout un outil, enfin pas un outil, mais un site avec des
formations sur les sujets que j'affectionne le plus, donc sur les tests, sur les cleanarchies,
etc.
Et aujourd'hui, je suis ravi d'être là pour parler à mes parents.
Ravie d'avoir, ravie d'avoir en board, comme on dit.
Partons de, on a, cher auditeur, on est parti d'une opportunité qui est eu Pierre d'écrire
pour le magazine programmé sur le TDD.
Et notamment, tu m'avais dit sur les préjugés liés au TDD.
Est-ce que tu peux nous en dire un petit peu, alors sans dévoiler tout le compte
d'une article, mais c'est quoi le top 3 des préjugés que tu rencontres sur le TDD ?
Alors je ne saurais pas comment les classer vraiment dans le top 3, mais disons celui que
je vois le plus souvent, c'est oui le TDD ou même plus généralement les tests unitaires
noix à lentisse, parce que dès qu'on bouge le petit doigt, il y a tout qui pète.
On ne peut pas réfactorer notre code parce que du coup, on doit tout de suite réécrire
les tests en permanence.
Ça, c'est une idée reçue que je vois beaucoup.
Alors ça, ce n'est pas forcément une idée reçue.
Quand tu fais les choses pas très bien, c'est ce qui peut arriver.
C'est exactement ça.
C'est une idée reçue qui est liée à une mauvaise interprétation et du coup, de fait,
à une mauvaise pratique des tests automatisés, donc à la forcierie du TDD.
L'idée reçue, ça serait que ce soit inéluctable en fait, que si tu fais du TDD, tu es obligé
de t'en chier sur la maintenance de tes tests.
Et en fait, c'est souvent un passage obligé au début pour comprendre dans la douleur
que ok, on ne fait pas bien.
Finalement, c'est très facile de savoir si on fait bien ou pas du TDD ou même des tests
de manière générale.
C'est que justement, si son fragile qui casse dès qu'on bouge le petit doigt, en
gros, dès qu'on réfactore le code sans changer le comportement, c'est qu'on ne
fait pas bien.
C'est qui un souci.
Oui, j'aime bien.
Ce que j'aime bien dire ça, le TDD, c'est un indicateur de la santé de ton code, la
facilité avec laquelle t'écris du TDD est un indicateur de la santé de ton code, mais
ça te donne pas de solution.
Ça te dit juste, tu es dans le caca ou ça va, mais c'est du quoi faire.
Et d'ailleurs, ça me fait penser à une idée reçue qui pour le coup est là une vraie
idée reçue, je pense, et que je n'ai pas mis dans l'article.
Et j'y pense là quand on parle, c'est le fait que le TDD, c'est magique.
Ça va nous faire apparaître du code magiquement et qu'on va trouver le meilleur algorithme
tout de suite, qu'on va trouver le meilleur design du code tout de suite, etc.
Et si tu prends le contre pied, c'est intéressant.
C'est pas...
Oui, parce qu'en fait, on a tendance à dire que le TDD, c'est bien parce que ça fait
émerger le design.
En fait, quand on pense à design, dans ces cas-là, généralement, on pense souvent
à architecture.
C'est la traduction du terme.
Voilà.
Alors, c'est faux.
Le TDD, c'est pas magique.
Ça ne fait pas émerger le design de ton architecture.
Il faut déjà, en amont de ta pratique du TDD, savoir ce qu'est une architecture testable,
savoir concrètement où vont se positionner différents éléments de ton code.

Le TDD permet de faire émerger un design local, c'est-à-dire sur un algorithme, par
exemple, ou quelque chose de localisé.
Mais il faut avoir en tête ce qu'est une architecture testable avant de pouvoir se lancer dans le
TDD de façon aveugle parce que sinon, c'est pas magique.
Ah non, complètement.
C'est vrai qu'il n'est pas le TDD qui te fait émerger design.
C'est celui qui fait émerger design, c'est toi.
C'est le développeur qui est derrière.
Par contre, ça peut t'aider parce que, par exemple, tu vas te rendre compte par la douleur
justement que c'est difficile de tester, par exemple, une date dans ton test parce
que ton test, voilà, en fonction du 6e vendredi, ça va se passer différemment pas.
J'ai eu le cas récemment avec un client.
Il y avait des slots de livraison à choisir et en fonction de son état le vendredi, la
semaine suivante, ça ne fichait pas.
Enfin, la semaine courante, ça ne fichait pas.
Il fallait que tu affiches uniquement la semaine suivante parce que tu ne pouvais pas être
livré cette semaine-là puisqu'on était déjà vendredi.
Et du coup, dans les tests, si tu te rends compte que, ah ouais, mais attends, je ne
vais pas attendre vendredi pour tester mon code, c'est hyper sûr.
Dans du coup, naturellement, tu vas te dire, OK, ce qu'il faut que je fasse, c'est que
là, j'ai une dépendance qui est sur le temps, on appelle une dépendance implicite parce
que c'est pas quelque chose qui est explicité dans le code forme de dépendance.
Je vais la sortir pour rendre mon code testable et de fait, ça, ça génère une abstraction
qui représente le temps.
Et donc, c'est en ce sens qu'on peut dire que le TDD, c'est aussi émerger un peu le
design parce que là, ça nous a fait prendre conscience qu'il fallait extraire cette notion
du temps et donc éventuellement la mettre derrière une interface.
Donc là, c'est là où ça peut rejoindre un peu le côté architecture.
Mais c'est pareil pour aussi quand tu as du random ou des choses comme ça, en fait, dès que tu as du code,
tu n'es pas testable, tu vas te dire, OK, pourquoi ?
Et donc, c'est là que ça te fait naître la modularité, ce genre de choses.
Mais il faut en amont savoir ce qu'est une architecture testable.
Voilà, il faut, c'est pour faire du TDD efficacement.
Il faut évoluer dans un contexte où tu sais, par exemple, ce qu'est une architecture
hexagonale ou du moins ce qu'est l'impression de dépendance pour pouvoir avancer
sereinement, comprendre à quel endroit tu veux amettre tel ou tel truc ou en tout cas,
comprendre que tu peux le mettre dans un certain, dans une certaine coude de ton application
et que tu pourras l'arifacturer à loisir plus tard.
Alors moi, quand j'ai...
La magique, comment ? Non, c'est pas magique, clairement.
Même j'ai fait le chemin inverse, mais en fait, j'ai commencé par le TDD.
Donc moi, j'ai commencé à faire du TDD il y a...
Oh mon Dieu, il y a 20 ans.
Un truc comme ça, il y a à peu près 20 ans.
Et à cette époque-là, on ne parlait pas d'architecter...
Quoi ?
Je disais que je n'étais même pas né, mais non, c'est une blague.
Je ne sais pas comment te faire heureux.
T'as quel âge ?
J'ai 31 ans.
Ouais, t'avais 11 ans, putain.
Et donc, on ne parlait pas d'architecture hexagonale,
parce que je crois que le concept n'avait pas été nommé encore.
Par contre, le truc qui était hyper trendy, qui était à la grosse mode,
c'était les design patterns.
Et moi, en fait, j'ai découvert la design pattern après avoir fait du TDD.
Donc moi, si tu veux, je suis rentré dans le code...
Je suis rentré dans l'extrême programming.
Voilà, avec...
Je pense que j'avais un certain don un peu inné pour l'architecture logicielle.
J'avais déjà pas mal codé.
Le problème de ça, c'est que quand tu as quelque chose dîné
ou que tu n'as pas conscientisé,
quand tu touches une limite, tu ne te rends pas compte.
Et puis surtout, tu ne sais pas progresser.
Et donc, j'arrivais à me débrouiller sur mon code,
assez en tout cas pour faire du TDD.
Et puis, il y a des moments où justement, je sentais que j'étais coincé,
mais je n'arrivais pas à m'en sortir.
Et c'est quand j'ai découvert les designs patterns
que j'ai réussi à progresser dans ma conception.
Et là, j'ai réalisé que, ouais, en fait,
tu peux faire du TDD sans savoir designer.
Mais tu vas vite galérer.
Tu peux designer très bien sans faire TDD.
Mais ton code sera peut-être plus testable,
mais pas forcément testable.
Et le top du top, c'est quand tu sais manipuler les deux.
Et tu veux même, et je peux même te dire un truc,
un petit secret de...
Enfin, quelque chose dont moi, je suis assez convaincu.
Mais je vais faire exprès de me faire l'avocat du diable.
Quand tu... à partir du moment où tu sais comment faire une architecture testable,
une application testable et tout,
tu pourrais presque te passer, d'écrire des tests ou les écrire après,
tu vois, limite, parce que tu sais comment t'as fait le...
Tu sais que ton code est déjà testable.
Mais ce serait idiot de faire comme ça,
parce que comme tu dois faire le boulot deux fois,
ce serait quand même plus long de les écrire après.
Mais voilà, c'était juste pour prendre un peu le exprès,
pour que je me fasse faire un peu l'avocat du diable
en parlant du test after versus test before du TDD.
Ouais, le truc, si tu les écrits après,
tu retombes dans le travers des cr...
Tu vas facilement tomber dans le travers des crits du verre sur du verre.
Ouais, ah oui, complètement.
Après, c'est sûr que tu peux rater des use cases complets,
enfin, des choses que tu n'auras pas vues,
parce que tu n'auras testé que la partie que tu sais va fonctionner,
mais ça ne t'aura pas amené à tester toutes les branches,
toutes les qui peuvent, du coup, potentiellement.
Ouais, ce qui est sûr, c'est que si tu as le design qui est déjà fait.
Ouais.
Ouais, je ne réfléchis pas comme ça, c'est vrai que je...
En fait, sur la blockchain, qui est vraiment mon activité d'aujourd'hui,
c'est un petit peu différent parce que le design est assez
et relativement simple, en fait.
Tu vas en général manipuler un contrat,
enfin, tu vas coder un contrat à la fois,
ce qui est un peu l'équivalent d'une classe,
qui va interagir en général avec
deux, trois contrats grand maximum,
qui va hériter peut-être d'un ou deux contrats grand maximum.
Donc, on reste sur des objets qui sont quand même assez...
pas assez gradulaires.
Et j'avoue que
je fais du TDD 50 à 60% de mon temps.
Et il y a pas mal, je fais aussi
parfois du test after, voilà.
Mais là, du coup, c'est plus la même chose,
tu vois là, je suis plus dans une logique TDD
de conception de ce que je fais,
je suis juste dans une logique de QA, validation.
Il y a pas de mal, tu vois, il y a pas de mal à écrire des tests après.
C'est juste que c'est pas pareil, voilà.
J'appelle plus à d'autres.
Ils ont pas le même...
Ça n'a pas le même but.
Ça n'a pas la même fonction,
ça n'a pas la même intention, tout à fait.
Le fois où j'écris des tests after,
c'est parfois pour les tests d'intégration.
Je ne les fais pas toujours en test first
ou voir en TDD quand je peux.
Les tests d'intégration,
je vais juste vérifier qu'une requête SQL
fait le bon truc sur ma base
ou des trucs comme ça,
ou sur Firebase ou autre.
Ça, je ne le fais pas tout le temps
en TDD,
parce que je fais beaucoup de copies collées sur ça,
de projet en projet.
Donc du coup,
ça, c'est la seule partie
où éventuellement, je ne fais pas spécialement TDD.
Quel nuance tu fais entre le test first et le TDD, toi ?
Le test first, tu vas écrire
tout ton test, voire tout tes tests, d'abord.
Ensuite, tu vas passer beaucoup de temps
dans le code et essayer de faire tout passer.
Le problème, c'est que tu perds complètement
le côté intégral,
enfin le côté intératif.
Et donc, tu perds la notion de feedback
rapide en le basant sur des petites étapes
à chaque fois.
Si tu fais un test trop grand d'un coup,
dans la complexité de ton algorithme,
par exemple,
l'exemple qui est souvent pris, c'est le jeu du bowling.
Si tu fais directement
ton test avec une partie de bowling
qui est relativement
cohérente,
avec des jets différents,
différents trucs, un peu de strike, etc.
Égal,
180 par exemple, comme score,
après, tu dois implémenter tout l'algorithme toi-même
et là, le test ne t'aide pas du tout.
Quand tu arrives à la fin, tu sais que pour ce score-là,
ça marche, mais déjà, tu ne sais pas,
forcément, si tu as bien géré tout les cas
du bowling.
Et puis, ça t'a pas aidé,
ça t'a pas aidé
à avancer, étape par étape,
les...
Ah oui, et d'abord, merci,
parce que c'est la première fois que quelqu'un
qui arrive à m'expliquer de manière
claire.
Mais ça veut dire que pour toi, le TDD,
il faut forcément y aller,
petite étape par petite étape, en fait.
Oui, par définition, parce que, en fait,
c'est le même situation.
Encore par définition, c'est drôle,
parce que cette notion de Baby Step,
c'est Canback,
qui fait qu'il en parle,
non seulement,
en fait, il en parle pas, c'est un cullbump,
je crois, qui a introduit la notion de Baby Step.
Et au contraire,
Canback, il dit,
vous avez une roue crantée,
et vous choisissez l'espace de vos crans, en fait.
Donc lui, au contraire, il est dans une logique de dire,
tu peux faire des petites étapes
ou tu peux faire des étapes plus grosses,
ça dépend de l'aisance que tu as avec
ce que tu es en train de manipuler.
En fait, si par exemple, tu fais un...
Les exemples des catas qui sont complexes,
au sens
règle métier, des choses comme ça, mais en fait,
90% du temps, dans nos applications,
on n'a pas forcément des règles
métier aussi complexes.
Et surtout pas aussi claires.
Et surtout pas aussi claires, forcément, mais du coup,
ça aussi, le TDD
aide justement à se poser les bonnes questions,
et du coup, c'est toute la démarche aussi,
behavior development tout ça,
qui pousse à parler un peu
des specs précisément
pour arriver à les modéliser dans sa tête,
pour ensuite justement pouvoir avancer pas à pas.
Mais tout ça,
c'est...
En fait, ça se...
Dans un
projet simple, où là, je n'ai pas d'exemple en tête,
mais par exemple,
je vais prendre l'exemple, je déteste
cet exemple parce que c'est toujours celui qui est utilisé,
mais il faut trouver que c'est l'exemple sur lequel
je vais bosser ces 6 derniers mois.
Donc ça a quand même du sens, c'est
la gestion d'un panier, notamment, et d'un process
de checkout dans le front.
En fait, que ce soit dans le front ou dans le back,
là, n'importe peu.
Mais par exemple,
quand je dois faire le test
d'un panier, toi, d'ajouter un panier,
si on se met en test first,
on pourrait tenter d'écrire des tests
du C-Lockage, d'ajouter un produit dans le panier,
ensuite on fait en sorte de retirer un produit dans le panier,
ensuite on fait en sorte d'ajouter un produit qui est déjà dans le panier,
enfin, on écrit tous ces tests là, la suite,
et du coup,
ça fait tout implémenter d'un coup.
Alors qu'en commençant petit à petit,
on va commencer par le cas le plus simple,
qui est ajouter un produit dans le panier, par exemple.
Ensuite, le deuxième cas le plus simple,
enfin, ça peut changer en front des gens,
on va juste se dire, ok, maintenant,
j'ajoute le même produit dans le panier, qu'est-ce qu'il se passe,
je demande sa quantité de 1, etc.
Enfin, toi, petit à petit, quoi.
Mais effectivement,
moi, ce que je fais, en fait,
c'est que je discrétis vraiment
deux choses dans l'écriture de mon test.
Je vais séparer
la structure du test,
de l'intention du test.
C'est-à-dire que, ce que je commence par faire
quand j'écris un test, c'est que je l'écris en entier,
donc je sais que ça peut être
un contraintuitif avec ce que je viens d'expliquer,
mais quand je l'écris en entier,
c'est écrit en anglais, quoi.
C'est-à-dire que je l'écris avec des phrases,
des fonctions qui n'existent pas,
pour que je puisse le lire, comme si c'était une spécification.
Il y a absolument zéro implementation
derrière dans le test, c'est vraiment
que des lignes de code qui disent, voilà,
étant donné que j'ai ça en entrée,
ensuite je fais telle action,
et bien il m'arrive telle truc.
J'écris la spécification, un peu comme si c'était un garkin, si tu veux,
mais surtout que c'est directement dans mon code.
Une fois que j'ai ça,
ça me permet de comprendre que
j'ai bien mon code
qui est... enfin, mon test,
qui est logiquement articulé,
avec une étape initiale claire,
une action claire, une étape finale claire.
Et une fois que j'ai ces étapes-là,
je commence à implémenter
la partie donc
Expect, l'Expectation, la dernière partie,
et je remonte petit à petit.
Toujours avec les étapes, quand je dis remonte,
c'est quand je passe à l'action, et après je passe à l'état initial.
Et toujours, par des petites étapes,
avec un feedback instantané,
surtout maintenant avec les...
dans nos idées, on a des trucs qui l'enfaient test automatiquement,
et on te voit directement si t'as une ligne de code qui est rouge,
ou pas, donc du coup,
en augmentant comme ça, mais je pars d'une structure
de code qui elle ne va pas changer, en fait,
et qui elle se veut complètement décoréler
de l'implémentation du test.
Au même titre que tes tests TDD,
enfin tes tests unitaires, doivent être décorérés
de la structure de ton code,
et bien moi, l'intention véhiculée par mon test
doit être décorérée de sa structure.
C'est-à-dire que...
Je ne sais pas si tu connais la chronique DEMP,
c'est Descriptive and Meaningful Phrase.
Moi, mon code, il doit être...
mon test, il doit être DEMP,
c'est-à-dire que ça doit être des phrases descriptives,
parfois peut-être même un peu verbeuse,
mais qui peut être compréhensible par un product owner,
notamment là, pour l'occasion, c'était le cas
dans la mission actuelle, le product owner
pouvait très bien lire les tests,
il ne le faisait pas spécialement, je vais pas te mentir,
mais on a fait le test, il a pu le venir,
il le comprenait, et après,
derrière, il y a l'implémentation du test
qui va être un peu plus grand du code
plus réduire, mais tout ça,
c'est dans le même langage, c'est pas...
il n'y a pas de couche d'indirection avec un guerkin,
avec un cucumber, tout est fait
dans le même langage.
Mais tu vois,
moi, quand je t'écoute, je me rends compte d'un truc,
c'est que je vais vraiment
adapter mon approche
selon les cas et selon
la situation.
En bon, en Extreme Programmer,
j'ai gardé ce réflexe
d'automatiser ma recette.
Dans l'Extrême Programming,
tu as vraiment ce rôle du testeur, qui a un rôle particulier
dans le job, c'est
d'automatiser la recette.
Et moi, j'ai gardé ce truc, alors il paraît
que ça porte un an, je vois le double diamant
ou je ne sais plus quoi, le double loop.
Oui, le double loop.
J'ai gardé cette habitude, moi,
d'avoir, quand je connais, quand j'ai des éléments
clairs de spécification de l'attendu,
au périm, à la
frontière extérieure
du code que je dois écrire,
du système que je dois écrire,
d'automatiser la recette,
c'est-à-dire d'écrire tous les tests
d'acceptance
que je vais avoir à faire passer.
Et ça, ça veut dire que,
à un moment donné, moi, ce que j'aime bien
avec ça, c'est que j'ai une espèce de barre de progression
parce que si je sais que j'ai, voilà,
faire simple, 10 tests d'acceptance,
et que j'en ai deux qui passent, c'est
une mauvaise mesure, mais bien meilleure que plein d'autres,
je sais que je suis à 20% de progression.
Et après, je pars dans
des cycles TDD où je vais venir, parfois,
beaucoup plus localement, parfois,
dans une approche bottom-up, dans une, parfois,
au contraire, inside in ou inside out,
les deux en fait.
Et j'ai pas de dogme sur ça.
Des fois,
je reconnais que les baby steps
sont souvent plus pertinents,
mais ce truc
de devoir d'enseigner le fait que c'est
indispensable,
ça me fatigue un peu, en fait.
En fait, c'est toutes
les questions de
conforme à l'expérience, c'est toujours pareil.
Il n'y a pas
de recettes magiques
qui marchent pour tout le monde.
Ça doit vraiment s'appliquer
à chaque équipe.
Ça doit s'appliquer en fonction
du contexte
de chaque équipe.
Et, par contre, pour en tirer
un maximum de bénéfices, il y a quand même une discipline
à avoir qui est dans l'extrême programming, notamment,
mais ça sert à rien
de faire bêtement
sans comprendre, en fait.
Si l'équipe est efficace en mettant
des tests qui servent, comme tu dis,
de barre de progression, bien très bien.
Ça permet de voir où on est,
de voir où ça avance. Il y a beaucoup d'équipes
le font aujourd'hui. Moi, je le fais
des fois aussi. Quand on fait des sessions
d'exemple mapping, par exemple, j'ai des exemples
qui me servent du coup à implémenter mes tests unitaires.
Je vais écrire le premier sur lequel je suis en train
de bosser et les autres. Je vais écrire
juste un titulé que je vais mettre en tout doux et ça me fait
pareil que toi. Je vois un peu ce que
je reste à faire, etc.
Et ensuite, ça, ce sont des exemples
que j'ai réussi à déterminer
à travers de l'exemple mapping
ou des choses comme ça. Et ensuite,
si je dois descendre d'un niveau plus bas,
là, on repart
sur des tests qui vont être plus bas niveau,
plus couplés à la structure du code, qui même vont
finir par sauter au final parce qu'ils vont être
couverts par les tests
de plus haut niveau.
Donc, il n'y a vraiment pas
une pratique...
Enfin, ceux qui prennent le dogmatisme
absolu, moi, je suis
peut-être naïf, mais j'ai tendance
à penser que c'est vraiment pour pousser vers
un pragmatisme éclairé. C'est-à-dire qu'il y a un moment
quand c'est important
d'être dogmatique au début dans sa tête
pour essayer de comprendre, selon moi,
pourquoi ça a été fait comme ça,
pour ensuite comprendre comment s'en écarter.
Tu vois, comment savoir
être souple.
Moi, ce que je vois dans les organisations,
c'est que il y en a beaucoup qui restent
après bloquer sur le côté dogmatique
du truc, soit ça provoque du rejet
chez les gens, soit
il reste dans une approche dogmatique
et toute manière
de faire différente et
quasiment hérétique.
Oui, c'est très vrai et je l'observe aussi.
Moi, je remarque qu'un déclic
quelque chose qui fait un vrai déclic
dans les gens avec qui je bosse,
c'est de dire que les tests
unitaires,
je vais dire doigts, ça assemble
les dogmatiques, mais en gros pour que ce soit efficace,
partent du niveau
du use case, donc de l'application layer.
Et pas directement
du domaine ou des trucs comme ça, tu vois, c'est les tests
qui sont les plus efficaces et donc en ce sens,
ça devient ce qu'on appelle des tests d'acceptation
unitaire et il remplissent
le même rôle que les
tests d'acceptation qu'on pourrait écrire
à un niveau plus haut
avec vraiment, je ne sais pas...
Tout ce qui est
une espèce de nommage, clature, test
unitaire, test d'intégration, test
unitaire, c'est une classe, pas une classe.
Ça me conflante un peu, moi je t'avoue.
Moi, ce que je retiens,
ce qui est important pour moi, c'est la démarche.
C'est vraiment la démarche du TDD,
c'est rouge, vert, vert.
Ça, pour moi,
pour le coup, je suis
un transigeant.
C'est important de savoir de quoi on parle, parce que
tu peux passer
toute ta journée, faire du TDD rouge, vert, vert,
et au final, à la fin de la journée, avoir un suivi
de tests fragiles qui va casser dès que tu vas réfacturer, parce que
tu auras fait ton test sur des détails d'implémentation.
Tu vois?
Moi, je te parle de nommage, tu me parles de tests fragiles,
tu vois, c'est deux choses différentes.
On peut passer très longtemps
à couper des cheveux en quatre pour savoir
si c'est un test
qui s'appelle comme ça ou un test qui s'appelle comme ça.
Moi, ce qui est important, c'est qu'il y a un test
et qu'il soit bien fait, tu vois.
Je crois que c'est Google qui a mis en place
ce truc-là, ça les a soulés aussi, tu vois,
que tout le monde a sa propre définition
de test unité, un test d'intégration, et tout.
Ils ont fait un test, ils ont écouté les gars,
maintenant on va dire, il y a des tests rapides et des tests lents, c'est tout.
Mais tu vois, ça me parle ça.
Franchement, ça, ça me parle.
Et moi, j'aime assez...
Ah oui, j'aime bien ça.
J'aime assez cet truc-là.
Pour les tests rapides,
ça va être tout ce qui est les tests unitels.
Donc là, ils peuvent en exécuter, je ne sais plus comment ils en exécutent
à la seconde, mais c'est un truc de phénoménal.
Et les tests plus lents, c'est avec les tests
typiquement d'intégration. Donc quand je dis d'intégration,
là je parle des tests d'intégration avec un
métier extérieur, donc une base de données,
un serveur peu importe.
Donc ceux-là sont nécessairement un peu plus loin de s'exécuter.
Et donc du coup, ils disent, voilà, nous,
l'idée, c'est que...
On ne le retrouve pas.
On ne le retrouve pas.
C'est un feedback rapide et basta.
Oui, ça, ça me plaît vachement.
Parce que cette espèce de guerre,
c'est comme la nommanclature des moques,
savoir si c'est un smart, un d'un...
Franchement, moi, je m'en tape,
tout ce que je veux,
si j'ai un jour, j'ai besoin de moquer,
c'est savoir utiliser le principe de moque
et savoir les utiliser.
Oui, mais tu sais, il y a aussi...
Enfin, je suis d'accord, mais il y a aussi une partie
où savoir nommer les choses,
ça permet d'y réfléchir plus facilement
et du coup de savoir les utiliser,
nous ne pas les utiliser quoi.
Je suis complètement d'accord avec toi,
mais c'est là que je te dis, peut-être que j'ai
une limite personnelle, ça ne m'apporte rien,
en fait, de mettre ces noms-là, en fait.
Voilà. Je me suis très personnel.
S'avoir si je suis en train de faire un test unitaire
ou un test de fonction, end-to-end,
en fait, ça ne m'apporte rien, en fait,
je suis en train d'avancer dans la construction
de mon soft.
En tout cas, pour deux personnes,
ils peuvent être en train de faire la même chose
et que l'un appelle ça un test end-to-end
et l'autre appelle ça un test unitaire.
Alors qu'ils sont en train d'écrire le même test.
Donc tellement les définitions peuvent varier
d'une personne à l'autre.
Mais je trouve que c'est un vraiment...
Aujourd'hui, ça simplifierait
si on avait tous les mêmes définitions,
parce que du coup on n'en parlerait plus.
On ne s'est plus en train de se dire que ça fait chier de se dire...
Oui, c'est vrai que ça, c'est rigolo que
que ce soit autant sujet encore à...
En fait, chaque endroit
a des manières de nommer les choses
différentes. T'as des strates un petit peu, tu vois,
même Mavan, maintenant, le côté end-to-end
est intégré. T'as différentes strates,
tu vas venir standardiser un peu les choses,
mais ce qu'on y met à l'intérieur.
C'est quoi les autres idées reçues que tu as ?
Une dernière idée reçue avant qu'on passe
à la deuxième partie de l'épisode.
Qu'est-ce que tu as relevé comme idée reçue ?
Une idée reçue
que j'aime bien, c'est qu'en gros
faire du TDD
c'est forcément plus lent, parce que
c'est plus de code à écrire, et donc ça coûte plus fière
nécessairement.
Et...
En fait...
Alors, là,
il ne faut pas faire l'hypocrite,
ça coûte plus fière au début.
Parce que forcément, on ne va pas se mentir
quand tu connais pas, quand tu apprends, etc.
Quand tu apprends, oui, bien sûr.
Voilà, c'est nécessaire.
Mais en fait, ce que je trouve très intéressant
c'est que Ken Beck, il est en train de créer un nouveau bouquin,
qui s'appelle...
Enfin, je pense que le titre est provisoire,
mais qui s'appelle Software Design, Tidy First.
Et dedans, il explique
que ce qui coûte cher dans le logiciel
c'est le coût du changement.
Et donc, plus le coût du changement est important,
c'est-à-dire que plus il impacte
beaucoup de zones du code, plus il revient cher, en fait.
Et donc, du coup, si plusieurs zones du code
devaient changer, c'est que le code, il est trop fortement couplé.
Et donc, le coût d'un logiciel serait donc majoritairement lié
au mauvais couplage dans le code.
Parce que c'est l'effet de Tidy First, tu vois.
Pourquoi pas, pourquoi pas.
C'est une théorie qui je trouve assez...
qui tient la route.
Et du coup, avec le temps, en fait,
ça devient plus en plus compliqué de faire ces changements
dans le code, parce que du coup, tu fais péter de fois
dans ta gauche, machin.
Et donc, c'est ce qu'on appelle les coûts de maintien
des stocks du logiciel.
C'est le fait que tu as du backlog, tu vois,
et que tu peux pas avancer, parce que
tu as des features que tu peux pas faire, parce que
tu es obligé toujours de, dès que tu fais de nouvelles features,
tu perds du temps. Voilà, c'est la rite fornelle.
Et donc, ces coûts, c'est tout le prix
de tout ce qui est délayé, finalement,
dans sa mise en production et qui aurait pu
apporter de la valeur à l'entreprise.
Donc, le TDD
force à écrire
les tests avant le code des productions,
et du coup, ça donne un feedback immédiat.
Et ça te permet d'éviter
d'accumuler trop de
d'aides techniques, pareil,
si on est honnête,
je pense que c'est
qu'à moins de travailler vraiment tout seul
dans un
exactement comme tu l'entends là-dessous, décollé en équipe,
il y a des trade-offs qui sont faits à droite à gauche,
même si tu es en TDD, il y a de moment, il y a
un peu d'aides techniques qui
peuvent arriver.
Non, mais on l'a dit,
de sans le TDD, il ne te donne pas de solution,
tu peux te revenir écrire en TDD, du code
de très merdique, des tests
très merdiques.
Tu peux même écrire
moi, ça m'est arrivé personnellement
d'avoir un
test qui était vert et tout, et avoir un bug
en prod, parce que, en fait, dans mon test,
dans les données de mon test, j'avais fait
2 plus 3, égal 7, tu vois.
Donc du coup, forcément, je testais que
je peux...
C'est pas magique, c'est pas magique.
Non, il y a des erreurs, ça arrive.
C'est juste que la promesse de le faire en TDD,
comme tu l'as dit, c'est que ça t'amène
à un code qui est mieux découplé,
ça t'amène à une capacité
à résoudre les bugs plus rapidement
parce que tu as un filet de sécurité et
un filet de détection, on va dire,
qui est beaucoup mieux fait. Donc moi,
je ne promets jamais à mes clients le zéro bug.
Par contre, ce que je promets, c'est de les régler
rapidement. Exactement. Et en fait,
pour conclure sur ça,
moi, je suis très d'accord avec
ce que dit Dave Farley
dessus, donc c'est un des auteurs
de Continuous Delivery,
où il dit, en fait,
que finalement, dans notre
l'ingénierie logicielle,
il faut qu'on fasse
comme c'est un sujet
très vaste et très, enfin,
on ne connaît pas en avant, on découvre
au fur et à mesure, il faut faire une série
de progrès par petites étapes.
Ça nous permet d'itérer
et d'avoir du feedback.
Et donc pour avoir ce feedback,
il faut qu'on fasse une série de petites expériences
où on définit, où on contrôle
les variables en amont, on définit nos hypothèses,
on effectue notre expérience
entre guillemets et on regarde, ça marche, ça marche pas
et donc on continue, on revient, on revient, on revient, etc.
Et en fait, c'est exactement comme
font un peu les scientifiques, ça se
rapprochasser de la méthode scientifique
où on a une approche très empirique
pour voir ce qui marche et ce qui ne marche pas,
d'autant plus qu'on est dans un contexte très changeant
et alors j'ai ma vie d'encore plus dans le domaine du Web 3
que je ne connais pas du tout, donc je me garderais bien
de dire des choses dessus, mais
où ça change très vite,
où on a besoin d'avoir du feedback pour savoir
si on va dans le bon sens ou pas
et donc c'est un peu
finalement ce que nous offre
le TDD, le TDD, enfin même sans parler
de TDD mais les tests unitaires de manière
générale, ça nous permet d'automatiser
finalement la vérification
de nos hypothèses en permanence sur notre code,
ça c'est quelque chose qui n'y a dans
aucune autre industrie, il doit d'avoir un feedback aussi rapide
dans la façon dont on avance
c'est extrêmement...
Mais je crois que de toute façon, il n'y a aucune industrie
qui permet de construire de la valeur aussi vite en fait.
Ben non, et surtout
qu'on n'est pas dans une industrie
de production, dans l'ingénierie
de manière générale, ce qui est compliqué quand tu fais
un téléphone ou quoi, tu vas le designer
une fois, ok, certes, mais après ce qui est
compliqué c'est de trouver comment le faire
en sorte que sa production soit scalable, donc il y a
toute une étape de chaîne de production
en déterminé, et donc ça
il y a des risques associés, des choses comme ça,
dans le logiciel ça c'est quasiment gratuit en fait,
tu vois, une fois que tu as ton truc, tu peux le dupliquer
ça fait juste du code, tu le dupliques et basta, tu vois
c'est... il n'y a pas de souci de tout.
Oui, je ne suis pas convaincu à 100%
tu as quand même des...
tu peux avoir des enjeux
de ce passage à l'échelle qui sont non négligeables quand même.
Certes, mais pas
de mes mortes de grandeur que d'une industrie classique
ou tu as vraiment des chaînes de production massives qui doivent être
avec des processus qui doivent être complètement changés
en fonction de...
Tu vois, nous si on
on néglageait un peu, tu pop un sabre
en plus et c'est bon quoi, tu vois, alors évidemment
que c'est pas si simple, mais comparer
à l'industrie classique...
Moi, j'ai vu des scale-up
c'était plus que
rajouter un serveur, tu vois, il y avait des gros enjeux
de... il y avait parfois des très très gros enjeux
de design,
de solutions donc...
Non, je pense que la passage à l'échelle est
un enjeu dans notre industrie aussi
par contre
je pense que c'est une des industries les plus rapides
qui soient en termes d'évolution
et de... je parlais de création
de valeur, mais je veux dire de capacité à créer quelque chose
et à le mettre dans les mains
d'un utilisateur, c'est...
je connais rien qui soit aussi
aussi rapide qu'en fait.
Et peut-être un problème de notre industrie
justement, c'est que comme on est tellement rapide, on a tendance
à pas forcément
reprendre les expériences
passées et à refaire la même erreur quoi.
Enfin moi, j'ai vu beaucoup de choses à mesure
que le frontaine se complexifiait, moi je suis plutôt
baccaine en de base, mais j'ai beaucoup bosse
dans le frontaine, pour ce qui est parti architecture dans le frontaine
et en fait j'ai vu plein de problématiques
qui commençaient à naître
dans le frontaine parce que le frontaine se complexifiait
qui sont des problématiques qui ont déjà été résolues
dans le baccan et du coup
on redécouvre un peu la roue, on parle un an et tout
et donc aujourd'hui je sais pas si avec le web 3
ça va être la même chose, si on va redécouvrir
des trucs qui en fait sont des problématiques qui exigent déjà
alors même si c'est différent, les problématiques du web 3
mais en fait...
comment dire ça ?
Le web 3 versus web 2
c'est quand même pas fondamentalement
sorcier, c'est à dire que soit tu restes
à l'extérieur de la blockchain et parce que
le web 3, bien souvent
un developer web 3 c'est un developer web 2
qui interagit avec la blockchain
donc en fait fondamentalement
du point de vue technologique
il n'y a rien de sorcier, c'est juste que
au lieu d'un tu interagis avec une interface
js, donc ton frontaine
il va venir taper, la seule différence
c'est qu'au lieu d'avoir un backhand
web
c'est un backhand blockchain
mais en fait
du point de vue du frontaine, ta guerre de différence
c'est ce que tu travailles avec un backhand qui est vachement
plus lent
et qui brasse
des concepts de métier
dont tu n'as pas l'habitude dans le web
parce qu'effectivement dans le web, chaque action
tu fais un call, tu fais un call HTTP
et puis c'est fait là où là tu vas passer
par des appels metamasques, c'est à dire des appels
qui vont demander
une transaction. Après si tu passes
du côté blockchain, c'est à dire ce que je fais
et le métier que je fais moi qui est de développer des smart contracts
là c'est très différent
c'est complètement différent, t'as des paradigms
différents, t'as des contraintes différentes
c'est l'écosystème
et la technologie et les considérations
sont extrêmement différentes
mais si tu restes du côté web
c'est à dire web 3 et que tu interagis avec
c'est juste un je te dis un backhand plus lent
si je suis un peu provocateur
donc dans ton expérience
précédente
ce que ça t'apporte maintenant
quand tu fais des vélos de smart contracts
t'arrives à récupérer des choses quand même
de...
bien sûr, tout ce qui est
principe
dans les trucs qui viennent d'abord
sur la testabilité, moi je joue encore
des contrats qui ne sont pas testés à 100%
ça me fait dresser les cheveux sur la tête
si tu veux, ils sont même pas couverts à 100%
quand tu sais que ton code il va être immutable et brasser des millions
moi ça me fait juste froid dans le lot
de me dire que le code il n'a même pas été
testé automatiquement
et ensuite
tu vois tous les principes de design
même si le design est plus simple, je vais retrouver
les principes de design, les principes
de responsabilité uniques, par exemple c'est un truc
qui est assez important
qui va s'exprimer une manière intéressante dans la blockchain
parce que tu vas avoir un compromis à trouver entre
fractionner ton code dans des classes
modulables
mais qui va générer des surcoûts de gaz
parce que sur la blockchain
tu payes à l'usage, l'utilisateur paye
à l'usage en fonction de la quantité
d'instruction machine exécutée
donc faire un extract
méthode, t'y réfléchis à deux fois en fait
c'est pas si évident que ça
tu vas tolérer
une partie
d'uplication
parce que tu vas optimiser tes gaz
ce qui prouve bien encore une fois
qu'il n'y a pas de solution
universelle et que tout dépend du contexte
et que c'est important de le avoir en tête
dans ce contexte là
il va falloir que tu fasses des trade-offs qui sont différents
c'est d'ailleurs ce qui m'a plu
et qui m'a donné envie d'y replonger
c'est que tu as des paradigmes tellement différents
qu'il faut revoir
des choses qui t'es complètement acquise
et revoir des choses que j'enseigne
depuis des années
tu parlais de cet article alors
tu parlais de cet article que tu as écrit pour le magazine
ce qui était intéressant c'est comment est-ce que tu en ai
arrivé
à être contacté pour cet article
ça a commencé je pense en février 2000
2020
j'ai commencé à poster en février 2020
sur LinkedIn
et petit à petit
comme ça naturellement
j'ai une communauté qui s'est créée
de gens qui me suivent sur LinkedIn
ou je suis actif aussi sur Slack
et donc
j'ai trouvé
ma communauté
c'était ce qui me manquait
d'avoir des gens avec qui je pouvais parler
de tous ces sujets qui me passionnent
les tests, architecture logicielle
c'est vraiment des sujets qui me passionnent
et donc j'en ai parlé
avec plaisir en partageant plein de choses
que je savais au fur et à mesure et en apprenant plein de choses au passage
et donc naturellement j'ai commencé
à construire comme ça une communauté
sur LinkedIn
et j'ai été contacté après
par Ardiane qui
m'a proposé d'écrire un article
dans le programmé
leur série qui va sortir en décembre je crois
et donc voilà c'est comme ça
qui est né
cette demande
mais en fait tout ça s'inscrit plus globalement
donc vraiment
une de mes passions aussi c'est vraiment de partager
ma connaissance
parce que je trouve que c'est le meilleur moyen
de la remettre en question
de l'interroger et de rester
ouvert à
prendre plus de choses aussi quoi
et justement tu as tout un
tu es en train de développer une offre
de type infopreneur
c'est-à-dire avec tout un
en catalogue ou au moins déjà une première formation
en ligne
un petit peu comme je fais moi aussi avec
le cursus Artisan Developer
et je trouvais ça hyper intéressant
de
d'évoquer un petit peu
ce parcours-là
parce que
c'est quelque chose que je
en tant que freelance aujourd'hui
que je trouve hyper intéressant
de pouvoir compléter un petit peu ces revenus
de freelance
par ce genre de
produits qui sont des produits d'infopreneurs
et je suis curieux d'échanger un petit peu
sur ton parcours là-dedans
comment tu réfléchis le truc parce que toi aussi t'es freelance
et quand on a fait l'épisode
tu m'as dit ouais c'est quand on a démarré l'épisode
en préparation là tu me disais
là c'est cool je viens de finir une mission
je vais pouvoir me reconst�ir un petit peu plus à ce projet là
comment tu perçois aujourd'hui
je crois que tu appelles ça craft academy
oui c'est ça ouais
comment tu as lout ton temps ton énergie entre les deux
quel est ton point de focus comment tu gères les choses
c'est depuis cet été
en fait j'ai levé le pied
surtout ce qui est craft academy, lignedine etc
parce que je sentais que ça devenait trop là
j'arrivais plus à gérer surtout que je manque
probablement de beaucoup de rigueur
et d'organisation là dessus c'est un peu
yolo comme on dit quoi je fais un peu comme ça
pour me concentrer
sur la fin de ma mission pour ensuite
prendre du temps donc c'est là où on en est maintenant
pour vraiment bosser sur craft academy
complètement
et donc proposer comme tu le disais
mon offre de formation
moi j'ai pour objectif vraiment
à terme de pouvoir bosser
moins pour des clients et plus pour craft academy
alors toujours bosser avec des clients pour garder
quand même les mains dans le code
dans des contextes différents
parce que ça alimente aussi
mes compétences
mais de pouvoir me concentrer plus à craft academy
pour vraiment proposer une formation
qui soit en adéquation complète
avec les besoins aujourd'hui
qui me sont remontés très souvent
et qui tournent autour des sujets craft
un domaine général mais qui en gros peuvent se résumer
à comment
construire des logiciels moins chers
plus performants et plus rapidement
si on veut aller très vite
j'adore ça, j'adore cette définition
je ne bouge pas je te la note
construire, mais c'est construire
elle n'est pas logice, je l'ai piqué à des pharellets
moins cher plus vite
plus surellement
attends mais c'est très bon
ça comme promesse, c'est très très bon
moi ce sera un peu la promesse
globale de craft academy
qui va être dispatché en plusieurs modules
pour l'instant
ça va être des modules
qui vont être comme leur nom
indique des modules
donc ça va être très spécifique
à un sujet donné
donc d'après les retours que j'ai globalement
tout ce qu'elle plus demandait vraiment c'est tout ce qui
t'ont des tests automatisés
le TDD finalement c'est pas
spécialement demandé et tout mais en fait
j'ai envie de dire que
quand on comprend bien les tests unitaires etc
le passage vers le TDD est très naturel
mais le TDD nécessite
d'avoir des condes naissances en amont
sur l'architecture logicielle
donc d'abord se concentrer sur les tests unitaires c'est très bien
donc ça ça revient beaucoup
et donc ce qui revient beaucoup aussi c'est
comment
comment appliquer la clean architecture
dans le front-end
ça c'est quelque chose qui revient beaucoup
parce que comme on le disait tout à l'heure
le front-end depuis plusieurs années se complexifient
énormément
il y a les mêmes problématiques que dans le bac pour plein de trucs
et des problématiques nouvelles
notamment de réactivité et de choses comme ça
qui peuvent être répondues
par des
des méthodes qui existent déjà dans le bac-end
depuis longtemps et notamment
tout ce qui est de clean archier
je n'aime pas trop parler de clean archier
parce que c'est un véhicule
tout un écosystème derrière
mais on va dire plutôt d'architecture
des couplets modulaires testables
pour tous ceux qui se demanderaient
tous les auditeurs qui se demanderaient
pourquoi est-ce que Benoit a fait la promotion de Crest Academy
qui pourrait être passue comme un
produit concurrent
la raison est très simple c'est que
d'abord Pierre je le vois plus comme un
confrère qu'un concurrent
et je pense que plus on sera
nombreux à porter cette voie et mieux les choses
se passeront et plus les gens seront heureux
et le monde meilleur
et puis surtout
il n'y a pas une manière d'enseigner les choses
et moi ce que je recommande aux gens
c'est d'acheter les produits de Pierre et d'acheter les miens
parce qu'en fait
chacun va emmener un angle différent
va avoir sa personnalité et sa manière de dire les choses
et c'est à force d'être au contact
de gens qui maitrisent le sujet
que les gens vont pouvoir apprendre
toi aussi et progresser sur ce chemin
parce que les expériences
personnelles sont différentes
et du coup comme je dis les angles vont être différents
toi on sent que tu commences à avoir une coloration
plus fronte, là ou moi je vais plus
m'intéresser ou pourquoi du comment des choses
et avoir une approche un petit peu plus fondamentale peut-être
ça me fait
ça me fait sourire parce qu'en fait on me contacte
souvent
en tant que défront alors que
moi je me sens pas du tout défront en fait
toi tu me demandes de faire
une page html machin et tout moi je suis resté
bloqué au css3 et encore
css3 du début donc il y a plein de trucs
j'ai fait 15 000 fois les trucs de la grenouille
pour le flexbox et tout
je suis toujours aussi nul enfin bref
je suis vraiment voilà mais en fait
moi je me définis plus comme
développeur d'un air général et après que soit front ou back
tu vois c'est des problématiques qui sont assez
assez similaires en termes de découplage
de code en termes de test en termes de tout ça donc
il se trouve que en ce moment j'agis
plus dans mon milieu du front end
mais ça s'applique aussi au back end
et alors du coup si on revient
à l'alternance entre
freelance et occupé de donc on a positionné
craft academy comme ton projet d'infopreneur
aujourd'hui
tu dirais que à peu près je sais pas
sur les 12 à 18 ans et mois
quelle est la répartition
du chiffre d'affaires entre ton activité
de freelance et
craft academy
99% de freelance
parce que en fait je vais pas du tout
marquer tes craft academy pour l'instant
tu l'as pas poussé encore
non non mon objectif va être d'arriver
à plus du 70-30
voire du 60-40
éventuellement donc vers
70-30-70 freelance 30
infopreneurs
l'idée c'est de
pousser vers ça mais pour l'instant
j'ai pas du tout poussé parce que j'ai fait
un cours d'introduction aujourd'hui sur le clean code
qui est disponible sur mon site mais que je n'ai jamais marquetté
il y a peut être une centaine de personnes qui l'ont acheté
depuis qu'il est sorti
pourquoi tu l'as pas marquetté
je l'ai pas marquetté parce que
en fait pour être très franc parce que je me suis dit
c'est pas la qualité que je veux donner
au cours suivant
je veux des cours qui sont de meilleure qualité
mais est-ce que tu n'es pas en train de tomber
dans le piège, est-ce que tu n'es pas en train de tomber
dans le piège du repousse pour avoir le meilleur
alors si au début
complètement mais maintenant du coup j'ai changé de stratégie
et tous les gens qui ont acheté ma formation
là jusqu'à
jusqu'à récemment
je vais leur offrir
l'accès
à la formation qui va venir
en échange de
qui m'aide à beta tester le truc
parce qu'en fait la formation qu'ils ont acheté initialement
je vais finir par la rendre
moins cher, à moitié graphite, à moitié payante
parce que je vais m'en servir pour faire
une sorte de funnel
pour partager
j'ai un e-book aujourd'hui que je partage
gratuitement et probablement qu'avec ce e-book là
derrière je vais proposer
une petite formation
15-20 balles qui est l'introduction
aux clean codes par mail
donc tu vois c'est quelque chose qui va être récurrent
une fois par jour, je vois à peu près
comment le mail ça fait et après proposer
d'éventuellement
voir la
vidéo de deux heures qui prend un exemple concret
de refactorer du code
vers des dizaines paternes, vers
d'émerger des notions métiers, des choses comme ça
là que je pourrais vendre aussi à la suite
et après en fin de
funnel, proposer
de participer
d'acheter en précommande le futur
court sur les états unitaires
tu as passé combien d'énergie à tout ça aujourd'hui
tu dirais en semaine, en mois
tu as passé combien d'énergie sur craft accadé
en fait là je vais surtout
mettre mon énergie maintenant
l'énergie que j'ai passé il y a
un an et demi ou plus combien de temps quand j'ai fait
la première formation
j'avais passé peut-être un mois je sais plus
à temps partiel
voilà un peu le soir, un peu le week-end
pour bosser dessus mais
le plus d'énergie c'était vraiment sur l'indine et de répondre
aux gens parce que je réponds à tout le monde qui m'envoie
des messages sur l'indine
je ne vais pas faire payer du coaching ou autre
il y a des gens qui viennent me poser des questions
des messages privés, j'y réponds avec plaisir
pas toujours tout de suite mais j'y réponds, je finis toujours par y répondre
et en fait
je me rappelle de quelque chose que j'ai lu
à l'époque où j'avais essayé de monter
une start-up dans le domaine de la musique
en 2011, 2012, 2013
j'étais inscrit dans la newsletters d'un mec
qui s'appelle de mémoire Kevin Stewart
un truc comme ça
et lui il avait une notion qui s'appelle le helpful marketing
et en gros il disait
il faut donner, donner, donner, donner au maximum
en vouloir aider sincèrement les gens
et du coup ne pas penser
en fait ah oui mais ça je pourrais
faire payer quand même parce que c'est quand même beaucoup d'informations
et tout non non tu donnes, tu donnes, tu donnes
et en fait en faisant ça tu crées une relation sincère
avec les gens qui te font confiance et qui sont prêts
du coup après à te soutenir quand tu proposes quelque chose
de plus abouti, de plus réfléchi
il faut quand même bien à un moment donné que tu gagnes un peu d'argent
sinon c'est pas durable
oui c'est pour ça que c'est dans les deux, non mais c'est de parallèle
c'est pas uniquement faire tout au début
toi maintenant j'ai une communauté qui me suit
je suis convaincu
qu'ils vont me faire confiance sur certains produits
et qu'ils vont aider, je vais en faire des messages
sur les gens qui me disent j'ai hâte
que tes produits sortent parce que j'attends avec impatience
voilà donc du coup ça motive énormément
ouais c'est cool
et du coup ta dernière mission elle a duré combien de temps ?
6 mois
c'était une mission de
et maintenant comment tu réfléchis la suite
tu te donnes un certain temps
tu te dis plutôt j'ai atteint un objectif
quand est-ce que tu reprendras ta prochaine mission
combien de temps tu vas aller louer à Craft Academy ?
c'est une bonne question
j'ai vu que j'avais un petit peu de trésorerie
pour tenir 2-3 mois
mais je vais voir avant la fin de l'année
je veux avoir sorti au moins un module de formation
avant la fin de l'année
donc là
cher auditeur qui va écouter cet épisode
dans plusieurs semaines après qu'il soit publié
on est le 3 novembre aujourd'hui
voilà donc ça se trouve quand vous les comptes
vous les coûterais peut-être que la formation
va être sorti
en fait blague et pas probablement
d'ailleurs
ouais donc vous allez très bien
mais ouais
en tout cas si tu tiens dans l'objectif de décembre
c'est peut-être très probablement le cas
ok
ça peut être aussi
un incentive pour le faire
mais voilà
c'est vraiment l'idée
après comme je disais il faut arriver
à se auto-discipliner
à se fixer des objectifs
parce que je ne fais pas assez moi
fixer des objectifs hebdomadaire, mensuel
de ce vers quoi je veux aller
pour vraiment ne pas se sentir en roue libre
parce que je sais que j'ai tendance à procrastiner
donc c'est
moi ça a été mon gros focus ces derniers mois
ça a été de travailler
tout ça en fait, travailler
tout ce qui est routine
tout ce qui est
manière de réfléchir ton projet
des structurations j'appelle ça les poupées russes
ça donne une vraie
il faut une vraie discipline
c'est une vraie ingénie de travail en fait
et sans grandit ça me manque un peu
honnêtement
c'est encore un peu yolo quoi
c'est l'occasion de faire un peu de teasing
je réfléchis sérieusement
à proposer quelque chose là-dessus
mais
j'attends d'avoir
une expérience un peu solide et robuste
de mon processus
pour avoir le proposer
mais oui c'est un vrai sujet
surtout quand en fait
quand un client c'est hyper facile
en fait tu es guidé par ton client et tu es arrivé
moi aujourd'hui tu vois je suis dans une phase
où j'ai besoin à titre personnel
de prendre du repos
des trucs plus ou moins cool qui sont arrivés dans ma vie
perso qui m'ont amené à vraiment
prendre beaucoup de recul par rapport au boulot
et du coup
je suis dans une phase où je suis à nouveau redrivé
plus par mes échanges qui ont
et c'est vrai que c'est confortable alors ça met un peu de pression
mais c'est confortable en fait parce que
tu sais qu'à telle date tu dois avoir livré tel truc
mais tu te puisses pas 50 millions de questions
tu te dis bon comment je fais pour y arriver
quand tu es complètement à ton compte sur un projet
du type craft academy
ou artisan developer ou sur un projet d'infopronariat
si ta vidéo elle sort pas
et d'ailleurs tu vois moi je suis à la megabourg
mais j'ai cassé mon rythme
youtube
le podcast j'arrive à le tenir
mais le youtube c'est très très difficile pour moi
j'avais commencé à mettre en place un truc
mais bon voilà le côté régulier
j'ai encore du prografer
y'a personne qui va venir t'engueuler
on se met la grosse pression
mais finalement
j'ai pas sorti ma vidéo du mois
ou mes deux vidéos du mois
personne qui va venir me dire oh elle est où ta vidéo
et puis tu as sensisté le cas
ça serait infâne et probablement
qui m'excuserait
et puis je lui dis ah désolé j'ai été à la bourg
il me dirait c'est pas grave
alors que pourtant
en fait c'est chacun de ces petits parcs
chacun de ces gestes que tu as fait
qui vont faire avancer ta boule de neige
petit à petit
et aujourd'hui qu'est ce qui fait que le podcast
il tient c'est très simple
c'est que la boule de neige
la boule de neige du podcast a sa propre inertie
et ça tombe tout seul en fait
c'est à dire que maintenant
c'est rarement
moi qui contacte les gens
plus comme je le faisais avant
de faire des espèces de campagnes
tiens y'a la saison qui arrive
y'a vraiment un rythme qui s'est fait
et je suis plus souvent contacté
je pense que les trois quarts des épisodes
la moitié est facilement je suis contacté
et l'autre moitié c'est moi au fil de l'autre
quand je suis sur LinkedIn
probablement je me rappelle même plus
comment on s'est échopé
et comment on a organisé ça mais probablement
j'ai dû réagir à un T-post
on disait ça serait cool qu'on soit sur un épisode
c'est rodé y'a la page
d'inscription tout ça et ça marche tout seul
tu vois là j'ai atteint le moment où la boule
a sa propre inertie
mais YouTube c'est pas le cas
pour moi c'était un peu achievement
unlock quand j'ai vu tout ça
parce que
comme je disais en préparation ou dans des podcast
je sais plus
au début je connaissais que toi
sur LinkedIn dans le domaine
c'est cool ça quelle influence
tu crois que ça a eu les publicisations
de lui plus avoir que j'ai pu faire
tu publiais pas beaucoup sur LinkedIn
c'est surtout après
mais moi j'ai surtout vu tes publications
YouTube et c'est comme ça que j'ai regardé
sur LinkedIn après
mais sinon c'était surtout podcast
les publications LinkedIn
j'en ai pas trop en tête
qui m'est marqué
c'est vraiment beaucoup plus YouTube
est-ce que ça a joué un rôle
dans le fait de te donner envie d'y aller
ou pas plus que ça
oui parce que comme tu disais tout à l'heure
je me suis dit plus on est
mieux c'est en fait
il faut vraiment
on est dans une industrie
où faut partager au maximum
parce que ça va très très très vite
et donc il faut partager au maximum
les fondamentaux qui eux changent moins vite
et sur lesquels on a tendance
à zapper un peu alors que c'est des fondamentaux
et qu'on les utilise tout le temps
en s'en rendant compte et que c'est important
de l'émitriser
ou en tout cas d'en avoir connaissance
et du coup chaque fois que je vois des nouvelles personnes
qui publient là dessus
en ce moment il y a beaucoup plus de gens qui publient sur le TLD
des anglais notamment
enfin je sais pas si c'est anglais enfin anglophones en tout cas
qui publient sur plein de sujets
liés au craft parce que bon le terme
ça se galvodait un peu c'était sûr
mais en deux ans j'ai déjà vu la différence
mais
c'est important de
parler, c'est important de partager
donc plus on aime je sais je pense
et du coup t'as pas répondu à la question
combien de temps tu te donnes pour avoir de reprendre
de rechercher une mission
tu as dit j'ai 2-3 mois de trésor donc c'est en gros
c'est que tu flottes un peu sur ça
ou tu fais un comment tu fais
je sais pas trop
j'aimerais me laisser en fait on va dire
si je veux l'avoir sorti avant la fin de l'année
je vais me laisser un mois
ensuite pour voir derrière
pour faire des
pour tester voir si ça marche
voir si ça prend et tout
et après éventuellement reprendre une mission
peut-être dix-six février
dans ta tréso-là
en fait tu es guidé par ta tréso
en gros vu que tu as 2-3 mois de tréso devant toi
tu te dis je suis prêt à investir
sur cette tréso-là, à manger dessus
pour donner le maximum
de chance à faire avancer
craft académique
et après tu rentres en taf et puis tu continues
et après
l'idée si ça marche en gros c'est que je reprenne un truc
en 2-3 mois
enfin je sais pas en 4-5ème
ou en 3-4 mois
ah oui l'idée ça serait que les revenus générent avec ça
tu unloques du temps
et tu ferais quoi de ce temps-là
bah plus de coaching
enfin mais c'est marrant parce que c'était la première mission de coaching que je faisais chez le client
que j'ai fait là
et j'avais du mal
à me considérer coach
enfin je pense que
ça l'a probablement déjà fait aussi toi dans des missions de coaching que tu as dû faire
au tout début
tu fais moi c'est ce que je suis vraiment
c'est le fameux syndrome de l'imposteur
donc probablement que je referai des trucs de coaching
parce que ça se prête plus à des trucs sur 2-3 jours
et pas
sur du temps forcément
mais ça sera peut-être des choses comme ça
mais
en ayant en tête que voilà en fait
je peux vraiment réellement apporter
d'un intérêt
réel
d'auparavant d'expérience
alors j'avoue que dans le syndrome de l'imposteur
ça m'est rarement arrivé
d'autres problèmes
mais comme je me suis lancé alors que j'avais
construit une solide expérience
ça m'allait
après j'essaye d'être clair sur ce que
je maîtrise ou pas
sur les choses sur lesquelles je peux accompagner ou pas
et c'est comme ça que j'élimine mon problème
parce que quand parfois je suis attendu sur ça
tu as par exemple le
dddd
c'est quelque chose qui m'a toujours intéressé, qui m'a plu
j'ai lu pas mal de choses
mais je me tends pas du tout expertoisse
c'est quelque chose que je n'ai pas creusé
ni expérimenté suffisamment
à titre personnel
donc je vais tout simplement pas me positionner là-dessus
si je jouais
à l'apprenti magicien
à faire semblant d'être expert du sujet sous prétexte
que j'ai une petite notoriété
qui serait crédible en plus
là je me mettrai moi-même
dans une position difficile
mais j'essaye d'être très très clair sur mes zones d'expertise
essentiellement le dddd
et le design qui permet
d'arriver à écrire du dddd
mais voilà
j'ai quelque chose assez si bien
par contre là-dessus je suis plutôt bon
ouais mais c'est bien dans la reconnaissance aussi
et tu vois aussi par exemple
je suis clairement pas expert de tous les langages
c'est juste pas possible
ah oui oui ça
je travaille toujours en synergie avec quelqu'un
qui lui connaît son langage
ouais c'est important
moi je suis plus intéressé par les concepts
que par les langages en eux-mêmes
ah bah oui sinon tu ferais probablement pas ce que tu fais
exactement
Pierre c'était très très cool de l'échanger
très très cool de t'avoir aujourd'hui sur le podcast
si les auditeurs veulent en savoir plus sur toi
sur ce que tu fais ils peuvent venir ou alors
LinkedIn vraiment c'est là où je suis le plus actif
mais alors mettra ton profil
et puis ton
domaines c'est aussi craftacademy.fr
c'est moi qui suis obligé de faire ta pub pour toi
craftacademy.fr
je le marquais pas mais
craftacademy.fr
c'est
sur ça qu'il faut se
se confronter au marché
qui va changer probablement d'ici à ce que le podcast soit sorti
ce sera plus la même page qui sera présenté
donc ça sera probablement
autre chose merci Pierre d'être venu aujourd'hui
merci à toi quand toi t'as cher auditeur
bah écoute j'espère que tu as apprécié cet épisode
je t'ai déjà parlé du cursus artisan
développeur dans cet épisode
tu parles si tu es intéressé pour revenir
sur artisandeveloppeur.fr
il y a un rubrique formation
moi j'ai surtout envie de te parler du cercle
le cercle qui est ce parcours de formation
des développeurs frilantes
situé toi-même frilante ou très intéressé pour le devenir
je t'invite à venir y jeter un œil
et typiquement les sujets qu'on a abordés aujourd'hui
comment est-ce qu'on produit
des produits
pour venir compléter ces revenus
et pu être dépendant d'une seule source de revenus
qui dépend essentiellement de notre temps
c'est typiquement le genre de sujet qu'on a abordé dans le cercle
si ça t'intéresse encore une fois artisandeveloppeur.fr
bien regardez
dans la rubrique ou le titre ou le je sais pas quoi
tu cherches le mot clé cercle
et tu trouveras ce qu'on y fait là-dedans
en tout cas une description
je te remercie et je te dis à bientôt