Bienvenue sur le podcast Artisan Developer,
l'émission qui combine technique et agilité pour partager la passion du code.
Aujourd'hui je suis avec Christophe Thibault, Christophe bonjour.
Bonjour.
Comme c'est la première fois que tu passes sur le podcast, est-ce que tu peux te présenter en une minute Christophe ?
D'accord, donc Christophe Thibault, je travaille chez Octo Technologique,
qui est un cabinet de conseils en architecture, en méthode, je fais aussi du delivery.
Mon travail c'est d'aider mes clients à améliorer leur pratique de dev.
Donc ça passe par de l'accompagnement, de la formation, de la facilitation aussi et du conseil.
Et ce qui m'a donné envie qu'on échange pendant cet épisode,
c'est que tu avais un point de vue que je trouvais intéressant.
Tu disais il faut arrêter de parler de dette technique, j'ai plus envie de parler de dette technique.
Et c'est drôle parce que j'ai l'impression que c'est une notion qui commence à devenir mainstream,
qui commence à être comprise, sur laquelle on peut s'appuyer pour argumenter.
Et toi tu viens et tu dis non, il faut arrêter de parler de ça.
Ah vas-y, fais-tu nous.
Je sais pas si j'ai envie de dire il faut arrêter de parler de la technique,
parce que j'ai du mal à me concevoir comme quelqu'un capable d'arrêter les gens de parler de quelque chose.
Mais en fait j'ai manifesté l'intention récemment avec mes collègues
et avec un cercle un peu plus large de personnes avec qui je travaille,
d'arrêter de parler de la dette technique au sens de la dette technique.
Alors je vais d'abord parler du sens 1,
qui est le sens que Warren Cunningham, quand il a forgé cette expression,
dette technique a donné à l'expression,
une équipe fait un projet et elle semble d'être techniquement,
c'est-à-dire qu'en fait elle déroge à son état de l'art pendant un petit moment,
mettons une semaine ou deux ou à mois en vue d'atteindre un objectif intermédiaire.
Et ensuite elle péra sa dette, c'est-à-dire qu'elle remettra son système à l'état de l'art,
tel qu'elle se l'est définie pour le constituer.
Donc par exemple...
Donc dans cette définition c'est un choix conscient de quelque chose
qu'on ne fait pas par rapport à un référentiel donné,
pour ensuite le récupérer.
C'est ça, en fait, exactement, on contracte une dette,
c'est-à-dire qu'on met notre état de l'art légèrement déficit,
on prend, je ne sais pas,
le premier outil qui nous vient pour finaliser une démo.
Ensuite on fait cette démo, on a du succès, on trouve des clients potentiels
et on remet notre produit à l'état de l'art.
Et ça, ça s'appelle sans d'étés techniquement.
Et c'est une opération, non seulement saine techniquement, mais indispensable,
à tout équipage.
Le deuxième sens de la dette technique, c'est de dire
dans cette base de code qui n'a pas eu des tests unitaires
pendant toutes ces années, qui n'a pas été relue,
qui a été faite de briquets de procs sur lesquels on a accumulé
des technologies, des frameworks, maintenant qu'il faut la reprendre,
c'est difficile parce qu'il y a de la dette technique.
Alors ça, pour moi, faire le posé, le diagnostic,
cette application est en dette techniquement,
en fait c'est une façon de dire, bah cette application,
elle n'est pas à l'état de l'art, elle a été faite sur les procédés
qui ne sont pas à l'état de l'art.
Le problème quand je dis ça, c'est que je ne mentionne pas
de quel état de l'art je parle.
Donc je vais prendre un exemple.
Je croise sur mon chemin chez un client
un programme qui a été écrit en C en 1982.
Donc je regarde ce programme, il fait quelques tâches relativement,
modérément complexes, mais évidemment il le fait
avec l'état de l'art du langage C en 1982.
Et donc tant que je ne veux rien faire de ce programme,
tant que je n'ai pas des intentions par rapport à ce programme,
comme par exemple de le faire évoluer, de le remplacer,
je ne peux pas dire qu'il est en dette techniquement.
L'état de l'art en 1982, c'était de prendre le langage C
et de coder des choses avec ce langage.
Et bien que je sache qu'aujourd'hui, si je prenais par exemple Rubi
ou Pluton ou n'importe quel autre langage,
j'aurais des facilités avec ce langage
qui rendraient en comparaison le langage C obsolète,
la solution en C obsolète.
Je ne peux pas affirmer que ma solution en C est en dette techniquement,
tant que ce n'est pas dans un contexte donné pour un état de l'art donné.
C'est-à-dire qu'est-ce que je veux faire avec
et dans quel contexte technique je me place par rapport à ce programme.
Donc pour résumer, dire d'une solution
qu'elle est en dette techniquement, comme ça,
sans autre élément de contexte,
c'est comme si je disais,
« C'est à plier, ce n'est pas de la qualité ».
Alors ça pose la question, c'est quoi la qualité ?
Si je vais dans un restaurant chic à Paris
où je vais payer mon repas 300 euros,
on va me dire que je vais dans un restaurant de qualité.
Mais chez Mac Donald, il y a aussi une direction de la qualité.
Donc la qualité, ça dépend du contexte.
Donc pour moi, l'état de l'art, ça dépend également du contexte.
Moi je te rejoins quand tu as dit
qu'on accepte temporairement une baisse de niveau
par rapport à un état de l'art donné.
Ça a tout de suite fait-il sur le point, effectivement,
mais est-ce que l'équipe a bien défini son état de l'art ?
Exactement.
Et ça repose aussi la question du temporaire.
Ce que je n'aime pas, derrière le concept de dette technique,
c'est devenu normal quelque part d'avoir de la dette technique.
C'est le côté, c'est l'autre piaisse,
c'est l'autre ouvert de la pièce du fait que ça devient mainstream.
C'est que finalement aujourd'hui, on s'habitue et tout le monde trouve ça normal
et on n'est plus dans quelque chose de temporaire.
Moi je soutiens que je suis assez en ligne avec toi.
De manière temporaire, ça peut être utile.
Et même il y a des fois où c'est une question de survie pour le projet.
Absolument.
Et à partir de là, c'est bon à prendre.
Le problème, c'est deux choses.
C'est quand tu ne le maîtrises pas, quand tu n'as pas conscience.
Et je pense qu'il y a beaucoup d'équipes qui n'ont pas conscience,
qui sont en train de faire de la non qualité.
Mais ce que tu amènes aussi, ce qui est intéressant, c'est...
Oui, mais est-ce que vous avez seulement défini ce qui était la qualité ?
Tu parles des tests.
C'est intéressant parce que souvent je le vois dans des dots,
des definitions of done, c'est-à-dire l'ensemble des critères
qui permettent de savoir si on a atteint le boulot, si le boulot est fait.
Mais dans l'effet, quand tu demandes,
tu n'es pas toujours qu'il y a des tests.
Bien sûr.
Mais en fait, je pourrais très bien commencer un projet avec trois collègues.
Et puis on définit l'état de l'art pour notre projet.
On en décide.
On fait un accadrage de projet.
Et on dit, si c'est un projet,
le code de ce projet va tenir sur deux scripts de 40 lignes.
Voici comment on va le mettre au point.
On va faire de reju de code.
Est-ce qu'il y aura des tests, il y a eu là-dessus ?
Non.
On pense que c'est pas nécessaire.
Et on a défini l'état de l'art, c'est parfait.
Donc la définition 1 de date technique, elle tient toujours pour moi.
C'est un procédé très utile, c'est une heuristique
qui marche très, très bien,
qui est même indispensable pour innover, je pense.
La définition 2, c'est simplement le mot générique
qu'on commence à utiliser dès qu'on veut dire
« c'est pas de la bonne qualité ».
Le problème quand on dit « c'est pas de la bonne qualité »,
c'est qu'on est vague, en fait.
Et un deuxième inconvénient,
une deuxième chose que j'aime pas dans ce terme d'état de technique,
c'est que d'abord,
il traduit une financiarisation de la profession.
Ça n'a aucun sens de dire
cette application, les développeurs sont en train de l'an d'été,
comme s'ils devaient quelque chose,
les développeurs font leur boulot,
ils s'améliorent,
ils se bricolent en état de l'art au début du projet,
peut-être qu'il y a aussi des standards chez leurs clients.
Enfin, tout ça fait l'objet de conventions ensemble.
Il ne s'agit pas de dire que,
j'ai lu dans un article récent,
un article très succinct et très médiocre,
à mon sens,
qu'on estimait à 300 milliards de dollars
le coût de la dette technique dans tous les systèmes informatiques
et l'auteur ajouté ce qui était dû
à des développeurs en train de travailler sur du bad code,
du code mauvais.
Donc là, je pense qu'on atteint le pompon,
on dit, bon, il y a de la dette technique,
c'est-à-dire de la non-qualité, c'est-à-dire du mauvais code.
Pour moi,
ce n'est pas travailler comme un ingénieur
que de parler comme ça.
Après, il y a quand même des...
Tu vois, regardez,
j'ai testé il n'y a pas longtemps,
j'ai réessuyé code Climat,
j'ai tourné son Arcube
sur des projets pour voir un petit peu ce qui me donnait.
J'ai découvert avec surprise
que maintenant, il te chiffrait ta dette technique.
D'ailleurs, chaque anomalie,
parce qu'une anomalie renvoie un référentiel.
Donc derrière chaque anomalie,
ils estimaient la durée que tu allais mettre
à corriger le truc.
Je me suis dit, tiens, c'est intéressant.
Et en regardant certains projets,
je me suis dit, mais en fait,
il est même possible de générer...
Tu vois, j'ai vu des projets,
en le faisant tourner sur plein de projets,
j'ai vu des projets où la quantité de dette
générée, parce qu'il te le chiffre en temps,
était supérieure au temps qu'il avait fallu
pour faire le projet.
Je me suis dit, c'est intéressant de voir ça.
Tu sais, Benoît, je pense qu'un jour,
il se trouvera des consultants pour inventer un outil
qui chiffrera le coût en euros,
ou en dollars, des sourires qu'on n'a pas pu s'adresser
en réunion, ou bien des mots qu'on n'a pas dit,
ou bien des soupirs qu'on n'a pas poussé assez fort.
C'est n'importe quoi.
La détectique, c'est une métaphore.
C'est une métaphore que Warren Cunningham
a probablement trouvé chez Weinberg,
d'ailleurs, parce que dans Quetti Sur Sur Vénagement,
Jerry Weinberg parle de dette de conception.
C'est-à-dire, à un moment où on fait un peu souffrir
sa conception pour atteindre l'objectif intermédia.
Donc, c'était une métaphore.
Donc, voilà, quelque chose d'assez commode
pour convenir d'une certaine heuristique entre nous.
Et il y a des gens, évidemment, qui l'ont instrumenté,
outillé pour la transformer en système.
Mais ce système, il est totalement faux.
Sur quoi je baserais le coût en euros,
ou en dollars, de la dette technique ?
Sur quoi ? Sur le coût du développeur ?
C'est quoi le coût d'une non-qualité
que je n'ai pas besoin de corriger ?
C'est une excellente question.
Il se produit de ce conclure là-dessus.
C'est parce que la boîte de travail passait.
Pour conclure, je conviens, dans mon travail,
avec moi-même d'abandonner la notion de dette technique numéro 2.
Je garde la notion de dette technique numéro 1.
Je n'utilise plus la dette technique
dans le sens général.
J'ai dit merci Christophe pour d'être venu aujourd'hui.
Si les auditeurs veulent en savoir plus,
ils peuvent venir ou sur ce que tu écris.
Il peut-il faire sur le blog Octo,
ou je ne vais pas tarder effectivement
à écrire sur ce sujet ?
Je pense que ça vaut le coup d'être dit.
Je t'ai remerci encore d'être venu.
Je t'en prie.
Quand t'as touché à l'auditeur,
j'espère que tu as aimé cet épisode.
Je t'invite s'il t'a plu à nous mettre 5 étoiles
qui t'aillent autant mettre le maximum
dans l'application de podcast de ton choix
et te marre pas de les sauver derrière.
Ça sera utile pour faire connaître le podcast
et diffuser plus largement ce message.
Je t'ai remercié et je te dis à demain.