Dans une série d’articles, nous avons déjà abordé le thème du concept de la dette technique et de ses interprétations, ainsi que des causes de son apparition et de son emballement. Nous allons aujourd’hui aborder le sujet de ses conséquences.

Un manque d’innovation récurrent

L’accumulation de dette technique aura un impact sur le budget SI mais également sur la bonne marche générale de l’organisation. En effet, les organisations qui remboursent régulièrement leur dette auront plus de facilité à innover. En revanche, comme dans le cas d’une dette financière, les organisations qui ne remboursent pas peuvent se retrouver dans une situation délicate. Elles consacreront l’essentiel de leurs budgets au paiement des intérêts de la dette technique (surtout la maintenance système). Le développement de nouvelles fonctionnalités pourtant porteuses d’opportunités ne bénéficiera lui que des maigres moyens résiduels.

Les équipes informatiques seront mobilisées sur des sujets de maintenance. Elles devront gérer la difficulté d’évolution (en particulier pour des demandes comme la mobilité), la dégradation des performances, difficulté de maintenance, la non-prédictibilité du système (comment va-t-il réagir à la modification ou à l’introduction de fonctionnalités ?) ou la fragilité du code.

On peut ainsi corréler l’efficacité des équipes de développement à la taille de la dette technique. Des chercheurs de l’Université du Montana ont proposé en 2014 une formule permettant de lier dette technique et temps passé par les développeurs pour réaliser une tâche :

L’interprétation est immédiate. Lorsque la dette technique augmente, à taille de système fixe, le temps consacré à chaque tâche augmente également. Les équipes sont donc moins efficaces lorsque la dette technique augmente. Cette réduction de l’efficacité est certes imputable à des difficultés techniques liées à la complexité architecturale fonctionnelle. Elle peut toutefois également trouver son origine dans des problèmes d’origine humaine.

Un impact humain considérable

Des équipes SI démoralisées

Le problème majeur est la démoralisation. Les équipes arrivent chaque jour au travail, sachant qu’elles devront passer une bonne partie de leur journée à essayer d’améliorer ou de faire évoluer un système rigide et complexe, parfois confus. Leurs actions sont souvent sans résultat immédiat ou visible, voire occasionnent des régressions. Les équipes devront sans cesse justifier le temps excessif qu’elles accordent à ce qui semble être de simples tâches sans valeur ajoutée visible des Métiers et des utilisateurs. Les équipes informatiques devront se consacrer à ce qui semble aux Métiers être de simples tâches sans valeur ajoutée visible ; elles auront alors sans cesse à justifier le temps excessif qu’elles y passent. Lorsque de nouveaux développeurs intègrent les équipes ou que des consultants interviennent, les collaborateurs en place savent qu’ils vont devoir affronter des regards déconcertés, habituellement légèrement dédaigneux.

C’est une situation que nous avons par exemple rencontrée en octobre 2017. Lors d’une réunion avec une dizaine de représentants d’une très grande entreprise, nous avons proposé une simple montée de version de logiciel. Selon le responsable du système, le premier point technique possible ne pouvait avoir lieu avant… mars 2018. Échange de regards consternés entre les managers. Personne n’aime travailler dans un tel environnement et, jour après jour, paraître impuissant ou improductif.

Une légitimité professionnelle mise en cause

Les membres de l’équipe informatique peuvent alors se sentir contestés. Tout devient difficile. On repousse les montées de version aux dernières limites de disponibilité. L’introduction de meilleures pratiques et d’innovations techniques fait l’objet d’oppositions larvées. La proposition de remplacer certaines parties du système par de plus modernes génère suspicion et appréhension. De manière générale, les équipes entrent en hibernation ; elles cherchent à intervenir le moins possible pour ne pas déranger la léthargie. Certains membres fuient, démissionnent, se désengagent voire partent en burn-out.

Une autre difficulté humaine potentielle est la survenue de conflits internes. Il n’est en effet pas surprenant qu’une telle situation amène des querelles au sein de l’équipe. Des lignes de front apparaissent, qui réelles ou pas, deviennent vite problématiques. Elles rajoutent du ressentiment à la frustration et à l’embarras, en plus des problèmes techniques eux-mêmes.

Un poids pour les Métiers également

La dette technique pèse ainsi principalement sur les équipes informatiques. Toutefois, même si par définition, elle est invisible aux yeux des utilisateurs (puisqu’elle correspond à des choix faits en amont de la mise en production applicative), ses effets néfastes peuvent finir par être ressentis par les utilisateurs Métier. Ce sera alors en termes de « passif Métier » (coûts Métier dus aux interruptions d’activité, aux violations, aux données corrompues, etc.) ou encore en termes de « coûts d’opportunité » (bénéfices résultant des nouvelles fonctionnalités qui auraient pu être développées si les équipes techniques n’avaient pas été mobilisées par des tâches de remédiation).

Ainsi, la complexité croissante de l’architecture fonctionnelle du logiciel induit des livraisons de plus en plus lentes. Ce qui incite sous la pression des plannings à négliger encore plus la (re)conception fonctionnelle. Ce qui augmente encore plus la dette. Ce qui ralentit les processus de livraison applicative. Ce qui augmente l’insatisfaction des utilisateurs, dans un cercle vicieux toujours plus conséquent.

« Si la dette croît suffisamment, un jour ou l’autre l’entreprise dépensera plus au service de sa dette qu’en investissements pouvant augmenter la valeur des autres actifs. »
− Steve McConnell (2007), “Technical Debt”, 10x Software Development

Une affaire de compromis

Donc, s’il est inévitable (et même souhaitable) de générer de la dette technique, il est indispensable de la maîtriser dès l’origine. Il sera nécessaire de prendre des décisions argumentées, principalement les meilleurs compromis. Ces compromis devront faire cohabiter deux éléments antagonistes. D’un côté, la volonté d’accepter de prendre des risques afin d’atteindre les objectifs Métier. De l’autre, la conscience du besoin de tempérer les attentes utilisateur afin de renforcer la qualité logicielle. C’est « Promettre moins pour livrer plus ».

Cependant, c’est généralement lorsque les effets les plus indésirables de la dette se font sentir et que le problème atteint un seuil critique que les organisations s’émeuvent. Elles commencent à rechercher les solutions pouvant remédier à cet état de fait. Il faut décider d’honorer ou pas la dette initiale. Faut-il continuer à investir du temps et des efforts pour régler le problème ? Les possibilités qui s’offrent sont alors peu nombreuses :

  • Ne rien faire et laisser la situation empirer.
  • Redévelopper ou remplacer l’application ou le logiciel (solution coûteuse, risquée et qui ne s’attaque pas à la racine du mal). Parfois la situation est trop dégradée mais l’organisation a déjà consenti des efforts importants ; on aboutit alors à un état de coût irrécupérable (« sunk cost effect »). Il s’agit de la tendance émotionnelle des êtres humains à continuer à investir dans quelque chose qui ne marche clairement pas.
  • Procéder systématiquement à des améliorations incrémentales, clairement la meilleure stratégie à adopter. À condition que la situation soit suffisamment « propre » pour que cela ne soit trop laborieux…

Pour cela donc, on s’attachera à (1) minimiser la création du capital initial de la dette et (2) rembourser régulièrement ses intérêts. Ceci fait l’objet du dernier article de cette série.