La dette technique, vue depuis le modèle Développement = Production :

1) des concepteurs imaginent un système, déclinent une roadmap, mettent en œuvre un projet

2) des développeurs écrivent le code, concrétisent le système, font marcher la technologie, et la livrent en production

3) après un temps plus ou moins long, le code du système présente un certain nombre de caractéristiques indésirables : la dette technique.

La dette technique, vue depuis le modèle Développement = Traduction :

— Trois acteurs (Métier, Technique, Management) aux objectifs complémentaires mais distincts partagent un projet commun.

— Ils s’accordent sur un certain état de l’art : celui permettant de traduire au mieux leurs idées vers un système utilisant la technologie.

— Au cours du processus de développement, cet état de l’art se désaligne. La traduction devient incohérente. Certaines idées sont perdues, ou déformées, voire détournées.

Voici quelques exemples de création de “dette technique” :

  • Un client fait produire à une société de conseil un “Proof of Concept”. Après démo et restitution des résultats du POC, le client demande à ce que ledit POC soit déployé en production. Les consultants insistent sur le fait que leur livrable ne constitue qu’une expérimentation et non un produit exploitable. Le POC finit tout de même en production.

  • Un projet de développement démarre sous les auspices de la qualité logicielle: l’état de l’art initial décrit entre autres les pratiques de tests automatisés et de revue qui auront cours. 3 mois plus tard, parce qu’une partie de la complexité du projet a été sous-estimée, et du fait que le risque de dépassement n’est pas partagé ouvertement, l’équipe technique, sous pression, sacrifie une partie de ses standards. Elle s’inflige alors cette ironie : puisque le problème est plus complexe qu’initialement prévu, on réalisera moins de vérifications, moins de revues, moins de tests.

  • En début de sprint, le P.O demande à l’équipe : “s’il vous plaît, pas de tâches de refactoring sur le board. Nous devons absolument finir les fonctionnalités. Vous vous ferez plaisir après la mise en production.”

Vous me direz : ces exemples ne sont pas de la dette technique. Ce sont des histoires de décisions Métiers hâtives, de mauvaise méthodo de projet, d’incompréhension mutuelle, de stratégie de gestion du patrimoine logiciel…

Pourtant tous ces projets ont commencé dans la cohérence. La dette technique c’est cela : la cristallisation, dans la technologie, de conversations qui ont perdu de leur cohérence.

Alors que faire ? On peut faire quelque chose ! Stay Tuned.

publié sur Linked In le 22/01/2023