Bienvenue sur le podcast Artisan Developers, l'émission pour les programmeurs qui veulent
vivre une carrière épanouissante. Prêt à passer au niveau supérieur ? C'est parti !
Pour le cursus Artisan Developers, quand j'accompagne des entreprises, des équipes en
entreprise, il y a 8 modules qui sont les 8 modules du cursus et à la fin de chaque module,
on prend un temps avec les équipes pour débriefer du module. Et si je te parle de tout ça,
c'est parce qu'en fait à la fin du module 1, j'utilise un jeu, un jeu de cartes que j'ai créé
et dans ce jeu de cartes, tu simules une équipe et cette équipe doit choisir son architecture de départ.
Est-ce qu'elle part en microservice ou est-ce qu'elle part dans une approche monolithique ?
Et puis en jouant, j'ai souvent cette question, si je sais que je vais en avoir besoin, pourquoi ne
pas le mettre tout de suite ? Alors j'avais jusque-là une réponse assez simple parce que tu vas tout
de suite payer la complexité de cette décision alors que tu n'en auras pas forcément besoin.
Tu vois, moi j'ai un exemple dans une startup que j'accompagne, on n'est pas mal impliqué
dedans, ça fait 18 mois qu'on est lancé et on commence à peine à distribuer l'architecture.
Je préfère parler d'architecture distribuée que de microservice qui est un peu trop un buzzword,
un mauvalise, un peu trop employé à tort ou à raison, donc parlons simplement d'architecture
distribuée. Simplement, en fait, on a commencé par une approche monolithique et puis on a mis en
soi un espèce de boucle interne par un seul serveur et puis on est passé à deux serveurs.
Et puis après on réfléchit à l'étape suivante et on y va progressivement. Et finalement,
je suis convaincu d'une chose, si on avait fait ça d'entrée, premièrement on n'aurait probablement
pas fait les bons choix de frontières et deuxièmement on aurait payé le prix d'une complexité
qui nous aurait ralenti et peut-être du coup empêché de signer les contrats qui ont justement
amené à la nécessité de cette architecture. En tout cas, on a maintenant beaucoup plus d'informations
pour faire les bons choix, j'en suis convaincu et je suis ravi qu'on ait attendu pour faire bouger les
choses. Alors finalement, si tu dis ça, c'était la réponse que j'avais jusqu'à maintenant. Mais en
écoutant Sandra Mancuso, une de ses conférences, j'aime bien la nuance qu'il apporte. Il apporte
un autre regard et il parle du point d'inflexion. De ce moment où tu dois prendre la décision,
finalement, entre une approche directe et une approche Big Front Design, tu sais que j'ai un point de vue
assez marqué pour l'approche directe. On remonte dans la lignée du Canebec, chaque décision prise trop
tôt est en Paris sur l'avenir et ce sont des paris qu'on gagne rarement. Juste deux citations de
Canebec, XP est en Paris. En Paris, il vaut mieux faire quelque chose de simple aujourd'hui et payer un
peu plus demain pour le changer si besoin et que de faire quelque chose de plus compliqué aujourd'hui
dont on aura peut-être jamais l'usage de toute façon. XP va à l'encontre des instants de bien
des programmeurs à cet égard. En effet, nous prenons l'habitude d'anticiper les problèmes. Quand
il finit par survenir, nous en sommes ravis, mais s'il ne vient jamais, nous ne nous en apercevons même
pas. Et ça, c'est quelque chose que je trouve très intéressant. C'est quelle est notre capacité à
réellement prendre du recul objectif sur les décisions qu'on a pu prendre et qui n'ont finalement
jamais été utiles. Et tout ça ressemble furieusement à ce qu'on appelle en psychologie le biais de
confirmation également dénommé biais de confirmation d'hypothèse, désigne le biais cognitif
qui consiste à privilégier les informations confirmant en saisie des préconçus ou ses
hypothèses et à accorder moins de poids aux hypothèses et informations jouant en défaveur de
ses conceptions. Tu vois, en fait, globalement, ce que ça dit ce biais de confirmation, c'est qu'on
va avoir tendance naturellement à choisir les informations qui nous intéressent. C'est-à-dire
que si tu as pu prendre dix décisions peut-être prématurées dont neufs qui ont été mauvaises,
mais une qui a été bonne, on va avoir tendance, le cerveau humain va avoir tendance à se focaliser
sur celle qui a fait juste sans forcément voir les neuf autres qui n'étaient pas forcément très
bonnes. Surtout que ces neuf autres décisions, tu vas peut-être les sentir au quotidien,
mais tu vas pas forcément les rendre extrêmement visibles. Et donc dans cette logique là,
Ken Begg nous dit ne faites pas de paris sur l'avenir, vous les padrez systématiquement. Et ce
que j'aime bien avec Sandro, c'est qu'il apporte une nuance dans ce raisonnement. Lui, il n'a pas de
chapènes, il n'a pas de partis pris entre l'approche directe ou l'approche Big Up from Design. Il
prend quelque chose que je trouvais intéressant. Il dit, il vaut mieux corréler le niveau d'investissement
dans une décision avec le niveau de certitude que nous avons sur les facteurs qui nous poussent à
la décision. Donc en gros, plus on est confiant dans les hypothèses qui soutendent la décision et
plus ça vaut le coup de la prendre tôt, si par contre on n'est pas confiant dans ces hypothèses,
il vaut mieux retarder le moment où on aura plus de certitude. Et de fait, Ken Begg et Sandro sont
plutôt cohérents, c'est juste que Ken Begg ramène à zéro la certitude que nous avons sur
la décision. Et du coup, si j'en reviens à la question de départ, pourquoi ne pas partir sur
des microservices tout de suite ? La réponse est bien assez simple, c'est qu'il y a une certitude
fondamentale. Tu sais bien que tu vas en avoir besoin au bout d'un certain temps. La question,
c'est Ken. Et cette question, eh bien elle change tout. Au final, j'aime bien l'ouverture qu'apporte
Sandro Mancuso, mais mon expérience me montre qu'on se trompe beaucoup plus qu'on le pense sur
ce qui est vraiment important et des priorités à mener. Du coup, je deviens de plus en plus minimaliste.
Et tu vois, si tu nous suides depuis quelque temps que ce soit dans l'arène, dans l'application qui
sous-tend un petit peu l'accompagnement qu'on fait en entreprise, on y va vraiment par hytération
de quelques jours. On développe un petit bout, on le met dans les mains de l'utilisateur et on
regarde ce qui se passe, comment la valeur livrée est perçue, utilisée et les feedbacks que ça nous donne.
Voilà, j'espère que cet épisode t'a inspiré. Si c'est le cas, on voit moi un petit feedback.
Benoit ArrobazartisonDeveloppeur.fr. Et si ça t'intéresse d'en savoir plus sur ce jeu de carte
que j'ai créé, que je suis en train de... que je réfléchis à Open Source et que je réfléchis à
diffuser, si ça t'intéresse aussi, on voit moi un email BenoitArrobazartisonDeveloppeur.fr et on
voit comment je peux te briffer dessus. À demain !