Janvier 2018 : un projet démarre, une équipe se met en place, on fait un cadrage, un chiffrage, on réalise, puis on fait évoluer une application.

Janvier 2023 :

🙂 l’application est en succès : elle contribue aux bénéfices de l’entreprise depuis bientôt 5 ans !

😉 elle a évolué avec les besoins propres au métier qu’elle sert, ainsi qu’avec l’infrastructure.

☹️ le code est difficile à modifier, parce qu’il est endetté : pas assez modulaire, il faudrait plus de tests auto, réunifier le vocabulaire, moderniser la conception… bref il faut réécrire l’application.

Mythe : la dette technique, c’est une érosion de la conception : le code “pourrit”, est sujet à l’entropie. Si nous ne mettons pas d’énergie à préserver l’ordre dans le système, celui-ci se détériore. Les solutions d’hier deviennent les problèmes de demain.

Réalité : TOUT ce que l’entreprise met en œuvre, déploie et maintient est sujet à l’entropie.

Paradoxe : Dans le code de cette entreprise, la dette technique règne. Mais dans son activité, non. Elle ne perd pas les dossiers de ses clients. Dans ses armoires (numériques), tout est (numériquement) bien rangé, ou à peu près. Au bout de cinq ans de fonctionnement, les employés ne disent pas : désolé, le fonctionnement du service est sujet à la dette technique, il va falloir refondre.

Relisons l’histoire, cinq ans ce n’est pas si loin : ce code dont nous disons qu’il est endetté jusqu’au point où seule la refonte est possible, il est le fruit d’un cadrage initial, qui était le rendez-vous de 3 acteurs :

  • le Métier, qui parlait résultats et délais
  • la Technique, qui parlait conception, et faisabilité
  • le Management, qui parlait coûts et pérennité

Entre ces trois acteurs, ça a bien fonctionné, et puis ça a progressivement cessé de fonctionner, dirait-on. Cette équipe là avait trois missions :

1️⃣ créer de la valeur (vite, si possible),

2️⃣ contrôler les coûts (gérer les ressources),

3️⃣ maintenir la maintenabilité.

Mais on dirait que la mission #3 a failli. Le code du projet est devenu comme un navire qui prendrait l’eau. Des consultants passent et prêchent : “un bateau ça se maintient… vous auriez dû réagir dès les premières voies d’eau”, voire pour certains : “ça ne flottait pas au départ de toutes façons.”

Où et quand la mission a-t’elle failli ? Est-ce que l’équipe Technique n’était pas assez Technique (c’est la thèse de la “dette technique”) ? Est-ce que le Métier ne voyait pas assez loin ? Le management n’était pas à son poste ?

Les entreprises adaptent en permanence les technologies à leurs besoins, et vice-versa. Quand elles se sont informatisées (pour certaines, c’était il y a 50 ans), elles ont appris à manager un système d’information. Comment se fait-il que le développement, l’art de traduire en code un système de création de valeur, cette activité qui se loue comme un service depuis plus de 50 ans également, conduise toujours à ce mur qu’on appelle la dette technique ? Qu’est-ce que nous n’avons pas appris ?

publié sur Linked In le 29/01/2023