Technologies

Comprendre et ma�triser la dette technique logicielle

---

La course � la r�alisation dans l'urgence de certains d�veloppements logiciels risque de laisser, demain, un lourd fardeau aux �quipes informatiques. Voici un aper�u des diff�rentes causes, diff�rents types, des risques, mais aussi des avantages de la dette technique, et des strat�gies pour la ma�triser.

Publicit�La dette technique logicielle est le co�t accumul� au fil du temps en raison de d�cisions de mise en oeuvre technologique qui privil�gient la rapidit� au d�triment de la qualit� et de la maintenance � long terme. Elle repose sur l'id�e qu'en prenant des raccourcis pour acc�l�rer l'�criture du code ou la mise en place de l'infrastructure, on s'expose � un surcro�t de travail en mati�re de maintenance, de s�curit� ou de gestion pour l'avenir. Par exemple, si le code d'une application rapidement mise en production est alambiqu� et difficile � mettre � jour et � entretenir, le temps ou les ressources �conomis�s au moment de l'�criture seront pay�s plus tard en frustration et en travail suppl�mentaire.

C'est Ward Cunningham, d�veloppeur, inventeur du wiki et un des auteurs du Manifeste agile, qui a formalis� l'id�e de dette technique. Il l'a expos�e succinctement lors de la conf�rence Oopsla (object-oriented programming, systems, languages and applications) de Vancouver (Canada) en 1992 : � Livrer un code pour la premi�re fois, c'est comme s'endetter. Bien qu'un certain niveau de dette puisse acc�l�rer le d�veloppement, il est crucial de la rembourser rapidement en restructurant le code. C'est lorsque la dette n'est pas rembours�e que le danger survient. Chaque minute pass�e sur du code qui n'est pas tout � fait adapt� � la t�che demand�e s'apparente � l'application d'int�r�ts sur cette dette. Des �quipes enti�res d'ing�nierie peuvent se retrouver paralys�es par la dette li�e � l'impl�mentation d'un code qui n'a pas �t� retravaill� �.

Le parall�le avec un pr�t bancaire

La dette technique est souvent consid�r�e de la m�me fa�on qu'un outil financier sans lequel on ne pourrait pas r�aliser quelque chose aujourd'hui. Comme un pr�t aidera un acheteur � tirer parti d'une opportunit� immobili�re sans disposer de la totalit� du prix demand� au moment de l'achat, une entreprise peut rester en phase avec ses concurrents et saisir des opportunit�s de march� en lan�ant un produit logiciel ou un service web avant que le code n'ait �t� perfectionn� en vue d'une maintenance � long terme.

Mais, d'un autre c�t�, accepter une dette technique de cette mani�re vous impose des charges que vous devrez g�rer pendant des ann�es, ce qui risque de paralyser l'innovation IT. Tout comme le remboursement d'un pr�t sur 30 ans signifie que vous avez pay� beaucoup plus que le prix de vente de votre maison - du fait des int�r�ts -, le d�ploiement pr�cipit� d'un produit logiciel pour �tre parmi les � premiers arriv�s � peut engendrer plus tard de nombreux jours-homme consomm�s au sein de vos �quipes de d�veloppement, d'assurance qualit� et de service client.

Trouver le bon compromis

Dans l'absolu, une dette financi�re n'est ni bonne ni mauvaise, et il existe des principes, tels que la valeur temporelle de l'argent, qui aident � d�terminer si la souscription d'un pr�t sp�cifique est une bonne id�e ou non. De la m�me fa�on, le concept de dette technique permet de r�fl�chir (et m�me de quantifier) les compromis n�cessaires pour le d�veloppement de logiciels sous la pression des march�s dans le monde r�el.

Publicit�Et, pour continuer de filer la m�taphore, il existe diff�rentes fa�ons de traiter une dette technique, tout comme il existe diff�rentes fa�ons de s'occuper de ses dettes financi�res. Vous pouvez effectuer de petits paiements r�guliers g�rables � court terme, mais qui finissent par co�ter cher au fil du temps, ou vous pouvez rassembler les ressources n�cessaires pour rembourser la totalit� ou la majeure partie de la dette en une seule fois. Dans le cas d'une dette technique, cela peut signifier accepter un travail quotidien afin de la r�duire coupl� � la perte d'efficacit� li�e � l'utilisation d'un code de mauvaise qualit� ; �laborer un plan effectif de r�duction de la dette ; r��crire le code et r�soudre les probl�mes au fil du temps ; ou encore, supprimer compl�tement le code initial et le remplacer par une version enti�rement remani�e.

Par ailleurs, le fait que l'expression "dette technique" ait �t� cr��e par l'un des inventeurs de la gestion de projet agile n'est pas une co�ncidence. Les m�thodes de travail agile sont souvent con�ues pour la prendre en compte et encourager les �quipes � pr�voir des p�riodes r�guli�res dans leur emploi du temps pour r�viser le code existant. Cela fait partie de la philosophie d'am�lioration continue de ces m�thodologies.

Quatre fa�ons de g�rer la dette logicielle

En 2009, un essai publi� par Martin Fowler d�taille une fa�on d'envisager les diff�rents types de dette technique. Le d�veloppeur et auteur a popularis� le concept de remaniement du code qui revient � traiter une grande partie de la dette technique logicielle. Son essai propose deux axes diff�rents pour cat�goriser celle-ci. Le premier consiste � opposer ce qui est planifi� et ce qui ne l'est pas, le second, � choisir entre t�m�rit� et prudence. Une gestion prudente de la dette technique consiste � la prendre en compte d�s qu'elle est contract�e ou �valu�e ult�rieurement dans le cadre d'une strat�gie sp�cifique, tandis qu'une gestion t�m�raire consiste � la laisser s'accumuler sans trop y penser. Les deux axes combin�s cr�ent un tableau comportant 4 approches de la gestion de la dette.

- La gestion planifi�e, mais t�m�raire : � nous savons que nous prenons beaucoup de raccourcis, mais nous n'avons pas le temps d'y penser ou de nous en pr�occuper - passons tout simplement la ligne d'arriv�e ! �

- La gestion planifi�e et prudente : � nous avons �valu� les risques de cette conception avant de la mettre en oeuvre. Nous connaissons les cons�quences auxquelles nous devrons faire face et nous avons un plan pour y rem�dier �. C'est le moyen de lancer rapidement un produit minimum viable (MVP) et d'anticiper un remaniement ult�rieur du code, une fois que la solution aura gagn� des utilisateurs et des parts de march�.

- La gestion non planifi�e et t�m�raire : � bous avons une �quipe de superstars et tout le processus va probablement bien se passer ! � Ce n'est en g�n�ral pas le cas.

- La gestion planifi�e, mais prudente : � nous avons d�couvert quelques probl�mes li�s � notre processus de d�veloppement initial, mais nous les suivons de pr�s, nous apprenons de nos erreurs et nous avons un plan pour y rem�dier �.

Cinq sources de dette technique logicielle

La dette technique vient de nombreux domaines de l'infrastructure technique, et pas uniquement du logiciel. Un pr�c�dent article publi� ici d�crivait ainsi 7 formes de dette technologique qui freinent la transformation des entreprises dont la dette de donn�es, la d�pendance � l'�gard de l'Open Source ou la dette d'architecture. Mais avec la dette technique logicielle, le diable se cache dans les d�tails. Voici 5 facteurs sp�cifiques qui conduisent � contracter de la dette technique :

- La course aux d�lais : les contraintes de temps obligent souvent les �quipes � prendre des raccourcis, qui conduisent � un code de mauvaise qualit�, qui doit �tre retrait� ult�rieurement. Dans ce cas, l'�quipe technique doit hi�rarchiser les t�ches de mani�re efficace et suivre les travaux report�s pour s'assurer qu'ils seront effectivement r�alis�s.

- Des exigences trop floues : lorsque les objectifs sont vagues ou mal d�finis, les �quipes peuvent produire un code qui ne correspond pas vraiment aux besoins. Le travail effectu� en amont pour d�finir des exigences claires peut s'av�rer payant par la suite gr�ce � un code plus propre.

- Du code mal �crit : une des principales sources de dette technologique vient d'un code mal �crit qui rend le d�veloppement futur et la refonte lents et inefficaces ; un code bien structur�, en revanche, est plus facile � maintenir et � int�grer avec de nouvelles fonctions.

- Une documentation inad�quate : s'il est mal document�, un code, m�me bien �crit, co�tera � votre �quipe de d�veloppeurs et � leurs successeurs du temps et des efforts inutiles. La mise en place d'une documentation solide d�s le d�part prend du temps, mais elle permettra en fin de compte de r�duire les efforts ult�rieurs.

- L'in�vitable �volution des besoins : m�me les bases de code bien con�ues n�cessitent une maintenance continue en raison de l'�volution des besoins de l'entreprise, des menaces de s�curit� ou de l'obsolescence des technologies. Le code peut � d�river � en raison de d�pendances avec d'autres lots applicatifs ou de modifications mineures qui ont des cons�quences inattendues. D'une certaine mani�re, il s'agit de la cause la plus insidieuse de la dette technique, et il convient de s'en pr�munir.

Mesurer et g�rer la dette

Dans le cas d'une dette financi�re, il est possible de quantifier la somme d'argent que l'on doit. En revanche, il est tr�s difficile pour une organisation de d�terminer le niveau exact de sa dette technique. Certains experts sugg�rent, par exemple, de mesurer le travail non planifi� de l'�quipe de d�veloppement, qui serait un �quivalent acceptable d'une mesure du temps pass� � nettoyer la dette technique dont elle a h�rit�.

M�me si vous ne pouvez pas chiffrer votre dette, vous devez tout de m�me la ma�triser. Andrew Sharp, directeur de recherche � l'Info-Tech Research Group, soci�t� d'analyse de la performance des services IT, conseille aux responsables informatiques de documenter leur dette technique la plus critique, de comprendre son impact sur l'entreprise et d'�tablir un processus clair pour la r�soudre. Comprendre sa dette technique est d�j� une premi�re �tape dans sa gestion. Il faut lui donner la priorit� dans les feuilles de route, la consid�rer comme un risque m�tier et s'assurer que, lorsque l'on contracte une nouvelle dette, elle entre dans la cat�gorie dette � planifi�e et prudente �.

Trois fa�ons de convaincre les dirigeants de l'importance du sujet

Malheureusement, il peut �tre difficile de convaincre la direction de l'organisation d'investir les ressources et le personnel n�cessaires pour traiter correctement la dette technique, car ce n'est pas un sujet � sexy �. La r�duction de la dette technique ne contribue pas de mani�re directe au chiffre d'affaires et, en fin de compte, elle ne s'accompagne que rarement du d�ploiement de nouvelles solutions � mettre en avant. Il existe cependant des moyens de mieux � vendre � cette d�marche aux dirigeants.

- Mieux vaut utiliser un vocabulaire business que technique. On parlera par exemple de � goulets d'�tranglement pour les revenus � plut�t que de � syst�mes Legacy �.

- Pr�senter la dette technique comme un risque business - un risque de manquer des opportunit�s futures � cause du temps perdu sur les probl�mes actuels - constitue une autre fa�on de faire �voluer la conversation dans le bon sens.

- Associer la dette technique � des projets innovants, la placer au m�me niveau que d'autres priorit�s informatiques et m�me l'int�grer dans un plan strat�gique � long terme qui en montre le retour sur investissement.

Vous ne pourrez jamais supprimer compl�tement votre dette technique. Mais avec la bonne approche, vous devriez �tre en mesure de la minimiser et de la g�rer - et ainsi d'en contracter davantage lorsque cela se justifie d'un point de vue technique et que cela peut faire avancer vos objectifs organisationnels.

Article r�dig� par

Josh Fruhlinger, CIO US (adapt� par E.Delsol)

Partager cet article