Pour gérer vos consentements :

Dette technique : 3 types et 3 approches pour la maîtriser

Cela se vérifie tout particulièrement lorsqu’on ajoute un nouveau système pour prendre des parts de marché : la dépense présente pour répondre au « time-to-market » est faite dans l’espoir d’un gain futur.

Attention cependant, tout comme les dettes financières non maîtrisées, les dettes techniques peuvent devenir un « poids mort » pour l’entreprise. En cas de difficultés trop importantes, elles accaparent les équipes et engendrent une évolution défavorable du rapport Run / Projet.
Cela est synonyme de baisse dans la capacité à livrer de nouvelles fonctionnalités, mais aussi souvent de démobilisation des équipes, voire de turn over. Dans les cas extrêmes, par exemple pour les entreprises avec des ressources limitées, cela peut devenir léthal si la direction n’est pas vigilante à cet indicateur Run/Projet.

C’est pourquoi dans ce premier article, nous avons identifié 3 types de dettes IT et 3 parades pour les traiter :

Dette technique opportuniste et plan de remédiation

Un concepteur sait, en général, qu’il y a deux façons de créer une fonctionnalité : la bonne ou la rapide.

La manière rapide n’est pas nécessairement la mauvaise, car elle consiste à ne pas faire de sur-qualité. Cependant, l’économie peut très bien avoir été faite au détriment de la scalabilité : la bonne idée d’un jour se révèle être un choix non pérenne. Bien souvent le concepteur est contraint de faire ainsi pour réduire le time-to-market.

Ce choix est parfaitement acceptable, mais il faut l’accompagner d’un plan de remédiation, pour assurer la pérennité du nouveau système une fois que celui-ci en sera en production. Dans le cas contraire, les dettes techniques vont s’accumuler petit à petit, ce qui entraînera inexorablement la baisse de la qualité de service pour les utilisateurs, la frustration des équipes en charge de la maintenance applicative et l’accroissement des coûts d’exploitation du fait des incohérences techniques et fonctionnelles à corriger continuellement.

Ce type de dette doit donc être tracé, pour permettre des actions de remédiation. En parallèle, un sponsor / product owner doit être tenu responsable de l’évolution de la dette technique sur son périmètre, et donc être objectivé sur ce sujet. La cohérence n’est pas un artifice.

Dette technique liée à l’innovation et pilotage des exigences

Dans le monde de l’IT, de nouveaux patterns et technologies apparaissent sans cesse. Il en va de même pour les usages.

Un choix de conception, à un moment donné, peut être remis en cause soit par une évolution des usages métiers, soit par l’apparition d’une nouvelle technologie entraînant une obsolescence fonctionnelle.

Ce type de dette finit toujours par apparaître qu’on le veuille ou non. Il est donc important de sensibiliser le sponsor / product owner à la nécessité de suivre la satisfaction des exigences sur son périmètre, afin de déclencher des actions de remédiation le cas échéant.

Dette technique « endémique » et vastes chantiers de modernisation

Ce type de dette est relatif aux vieux systèmes, sur lesquels ont été empilées au fur-et-à mesure des demandes d’évolution de nouveaux traitements complexes, sous forme de « verrues », jusqu’à créer une complexité telle que les systèmes deviennent impossibles à maintenir / faire évoluer, sans parler du turn over, entraînant inexorablement une amnésie informatique.

Dans le cas de fonctionnalités critiques pour le métier, cela constitue un risque opérationnel pour l’entreprise.

Ce type de dette doit être évité autant que possible, et faire l’objet de vastes chantiers de modernisation. Souvent, cela implique un remplacement pur et simple du système par un nouveau, plus adapté, et surtout mieux conçu.

Il existe aussi d’autres types de dettes, notamment celles créées inconsciemment

Dans tous les cas, un système de classification des dettes techniques va permettre de les identifier et de sensibiliser les donneurs d’ordre, et leur proposer des plans de résolution adaptés :

  • Plan de remédiation pour favoriser la scalabilité et la pérennité au fil de l’eau
  • Pilotage des exigences pour accompagner l’évolution technologique
  • Vastes chantiers pour faire face à la dette « endémique »

Recent Posts

La « chasse aux risques » : une force proactive au service de la cybersécurité

La traque des risques ne devrait pas se limiter à la conformité réglementaire. Ces audits…

2 jours ago

La lutte contre les menaces internes est l’affaire de tous

Faute de solution miracle, les entreprises souhaitant se protéger de ce type de menaces doivent…

1 semaine ago

Cinq tendances qui bouleversent la connectivité Cloud

Une des thématiques émergentes en 2024 sera de ré-évaluer le socle constitué par le réseau…

2 semaines ago

Responsable de la sécurité des systèmes d’information : un poste sous les projecteurs

Dans un environnement où les menaces sont de plus en plus aiguisées et où les…

2 semaines ago

NIS2 : A l’aube de sa mise en application, les enjeux sont de taille

Même si la directive propose un mécanisme de proportionnalité en termes d’exigence, en fonction du…

2 semaines ago

Informatique quantique : la cybersécurité dans tous ses états (en même temps ?)

La cybersécurité est plus que concernée par les révolutions induites par l’informatique quantique. S’il est…

3 semaines ago