Opinion : est-ce que j'ai une dette technique IT, et comment la traiter ?

 

Comment savoir que votre dette technique IT est un problème ?

1. Vos coûts de maintenance des systèmes augmentent-ils ?
2. Trouvez-vous difficile d'embaucher des personnes pour travailler sur votre projet ? Est-ce qu’il y a d'ailleurs encore des gens qui maitrisent les technos qui vous posent problème 😊 ?
3. La modification à la marge du projet sur lequel vous travaillez prend-elle beaucoup plus de temps qu'il y a un an ?

….

Si les réponses sont positives, cela pourrait signifier que la dette technique IT de votre organisation augmente et finit par obérer l’agilité de votre entreprise.

Les recherches de Stripe suggèrent que "le développeur moyen passe plus de 17 heures par semaine à traiter des problèmes de maintenance, à gérer la "dette technique IT ". Inquiétant !

Pourquoi parle-t-on de « dette » technique IT ?

La dette technique fonctionne de la même manière que la dette financière. Si le prêt n’est pas remboursé, les mensualités ou les annuités s’empilent augmentées des intérêts, et le montant à rembourser finit par être bien supérieur au montant initial du prêt. Plus longtemps vous ignorez la dette technique, plus vous créez d’"entropie", et plus ça finira par coûter cher.

La dette technique n'est pas forcément mauvaise. Presque toutes les entreprises sont « endettées » dans une certaine mesure ! Le désordre est consubstantiel à l’activité, c’est la définition de l’entropie !

Helas, les utilisateurs finaux ne remarquent que très peu la dette technique, et les utilisateurs finaux sont souvent... les décideurs. La qualité du service ne sera que très rarement affectée d’emblée, mais ça ira crescendo, et ça finira par poser de réels problèmes. Il est donc urgent…de ne plus attendre !

Des origines humaines

Humainement parlant, la partie la plus ancienne des systèmes d’information (« legacy system »), est aux mains d’une population de spécialistes dont le nombre ne cesse de se resserrer jusqu’à disparaître. La dépendance des entreprises vis-à-vis de quelques profils peut être dommageable.

La transmission des compétences ne se fait plus, ou de plus en plus difficilement.

Plutôt que de supprimer ou transformer des couches techniques qu’elles soient récentes ou plus anciennes, on les empile pour ne pas prendre de risque. On repousse continuellement l’ambition partagée de systèmes simples, modernes. On contourne le problème au départ des technologies les plus récentes pour adapter et gérer le format de données plus ancien (compatibilité ascendante).

L’exemple le plus parlant réside dans les innombrables lignes de code Cobol qui commandent à de (trop) nombreuses applications dans le monde bancaire en particulier. Par contre, en cas, de pépin, il faut trouver un coboliste, ce qui n’est pas forcément aisé !

Mesurer la dette technique

La dette technique dans l'architecture est difficile à mesurer - il n'y a pas de métrique unique pour le faire, hélas. Ces métriques sont spécifiques à chaque projet. Quelques pistes :

1. Mesurer le temps qu'il faut pour faire tourner les chaînes d’alimentation (sans erreur) qui sont montées au plan, identifier, toutes celles qui ne tournent plus.
2. Calculer théoriquement un ratio entre le coût de remédiation et le coût de développement d’une nouvelle réponse technique. Si ce ratio est élevé, cela signifie que la dette devient importante ☹
3. Mesurer le degré de.... "bonheur" des équipes ! Soyons francs, si les équipes data sont de plus en plus agacées lorsqu'ils travaillent sur un projet, cela pourrait signifier qu'il y a une forte dette technique dans le système !
4. Le nombre de « bugs » : après chaque itération, il faudra mesurer le nombre de bugs sérieux non corrigés. Cela permet de planifier la charge de travail pour l’itération suivante. Il faudra mesurer le nombre de tickets ouverts versus le nombre de tickets fermés. Cela permet de savoir clairement si l’équipe va dans la bonne direction.

Traiter la dette technique comme une composante de la stratégie de l’entreprise

Une étude du Gartner indique que les entreprises qui ont une stratégie de dette technique mettrons leurs projets en production 50 % plus rapidement.

1. Il faut intégrer la résorption de la dette technique dans la feuille de route des projets : corrections des bugs, revues de code récurrentes pour créer des réponses plus résilientes.
2. Il faut convenir avec les équipes d’un temps consacré à la gestion de la dette technique. Cela n’empêche qu’il peut y avoir des sprints durant lesquels on en fait abstraction. Mais ce temps doit être rattrapé ultérieurement, et donc planifié.
3. Refactoriser le code : La refactorisation est un processus systématique d'optimisation du code et d'amélioration de la structure interne sans créer de nouvelles fonctionnalités. En d'autres termes, le re factoring transforme un code impropre en un code propre sans altérer son comportement externe.
4. Certains logiciels permettre de réécrire du code en le réécrivant préalablement dans une technologie pivot sous forme d’arbre algorithmique. Cela permettra de se départir typiquement des vieux codes procéduraux type COBOL, PL/SQL, ou Perl pour envisager des bascules vers de techno qui se marient mieux avec les architectures cibles, typiquement dans le Cloud (Python, NodeJS…).
5. Il existe des outils qui permettent de partager la complexité du système d’information, de définir ce qui sert, et ce qui ne sert pas, pour évincer de façon massive et systématique le « code mort » ou tout ce qui construit l’information sans qu’elle ne soit consultée. Il pourra être opportun également d’harmoniser les pipelines de données, ce que peut permettre l’IA. Ce processus sera très utile quand il s’agira d’organiser des migrations Cloud.

Synthèse

La meilleure option est d'éviter la dette, mais c’est un pari perdu d’avance. Mais il ne faut pas considérer que le "big bang"est la solution, même s’il existe des possibilités de cet ordre. Les évolutions durables itérative sont souvent meilleures que les révolutions. Il faut donc partager la complexité, et partager les capacités d’introspection et de correction. 

Quelques outils permettant de factoriser, de traduire le code. Ils auront un intérêt pour sortir de certaines ornières. Il faut aussi tenter d’évincer les pans entiers des systèmes qui ne tournent plus pour avoir des systèmes certes imparfaits, mais plus compréhensibles. Aucun projet d’avenir d’envergure ne pourra être conduit sans la prise en considération de cet enjeu, et ça, c’est une certitude.

#ITdebt #greenIT 

www.ellipsys-bi.com 

ellipsys@ellipsys-bi.com