09 Mar La dette technique
La notion de dette technique vient de fêter ses 30 ans. C’est en 1992 que Ward Cunningham a proposé ce terme pour appliquer au développement logiciel ce concept bien connu des financiers. Dans un rapport direct au temps, la dette technique apparaît lorsque la rapidité de développement d’un projet prime sur la qualité de sa réalisation. Car cette précipitation va demander davantage de travail de correction en aval.
Nous sommes donc à l’opposé du « doing it right the first time » bien connu des experts en lean management et qualité totale.
A l’insu de son plein gré
La dette technique peut parfois être « volontaire ». Comme lorsque l’on fait, en pleine connaissance de cause, un emprunt auprès de son banquier. Le dirigeant sait qu’il va devoir rembourser, souvent dans un délai assez court. Pour la dette technique volontaire, de la même façon, l’organisation accepte cette dette pour gagner du temps mais se prépare à combler rapidement cette dette en corrigeant le code défectueux. Un article de zdnet propose d’ailleurs de distinguer entre les dettes quotidiennes, hebdomadaires ou mensuelles.
Mais c’est plus grave lorsque cette dette est « involontaire ». Les responsables ne sont alors pas conscients que leur organisation technique est construite sur du sable. Cette dette obscure, ou « dark debt » est souvent un produit de l’augmentation de la complexité et de l’hétérogénéité du système d’information.
2 exemples concrets
La dernière panne de twitter est un bon exemple de dette technique. Un ingénieur travaillant en solo (il paraît qu’il n’en reste plus beaucoup depuis le rachat par Elon Musk) pour fermer les accès gratuits à l’API a mis en carafe nombre d’autres fonctionnalités. Le turbulent dirigeant a d’ailleurs réagi après analyse des causes du problème « « Un petit changement d’API a eu des ramifications massives. La pile de code est extrêmement fragile sans raison valable. Il faudra à terme le réécrire complètement ». Elon Musk avait bien quelques doutes sur le nombre d’abonnés fictifs quand il a négocié des milliards en moins pour le rachat de twitter. Mais il n’avait sans doute aucune idée de la complexité du code ou de sa mauvaise qualité. Lors du rachat d’une entreprise, les repreneurs peuvent avoir de mauvaises surprises si les vendeurs ont maquillé la comptabilité. Les dettes techniques sont bien plus difficiles encore à déceler.
Un exemple plus ancien de dette technique a carrément faillit mettre en péril notre civilisation. Vous rappelez vous du passage à l’an 2000 ? Pendant des décennies, le stockage de chaque digit supplémentaire coûtant cher, toutes les années étaient notées sur 2 chiffres. Impossible alors de savoir si une date concernait 2000 ou 1900. Des centaines d’années hommes ont été consacrées à préparer les gros systèmes informatiques, en particulier ceux des banques et ceux gérant les systèmes de transport et d’énergie. La bascule s’est finalement déroulée sans problème majeur. Ouf…
Pourquoi maintenant ?
Pourquoi donc parle-t-on à nouveau de la dette technique, 30 ans après la création du terme ? Tout simplement parce qu’un virus s’en est mêlé. Pas un virus informatique, non, mais le trop bien connu Covid 19.
Pour faire face au choc soudain du COVID et du confinement, beaucoup d’entreprises ont mis en place très (trop) rapidement de nouveaux outils informatiques (visioconférences, outils collaboratifs…) sans réel accompagnement. Dans ce cas la dette technique ne se cache pas seulement dans le code mais aussi dans le fait que de mauvaises habitudes vont demander beaucoup de temps avant d’être corrigées. Et il est plus simple de corriger des lignes de codes que les mauvais réflexes acquis par des centaines de collaborateurs.
Même avant le choc COVID, la multiplication des outils en accès libre, en mode freemium, a commencé à préparer de futurs dégâts. Perdus au milieu des Trello, Airtable, BaseCamp, Microsoft project, Workplace … les utilisateurs ne savent plus où donner de la tête ! La nouvelle mode du « no code » risque aussi de préparer de nouvelles dettes techniques.
La guerre des talents est omniprésente pour les compétences informatiques mais une récente étude du cabinet INSIGHT pour IDG/Foundry classe le problème de dette technique en 3 ième position des préoccupations des directeurs de systèmes informatiques, juste derrière les compétences et les budgets.
Si la lecture de ce billet vous a convaincu qu’il est important de suivre la qualité de vos outils informatiques et la façon dont ils sont utilisés par vos collaborateurs, prenez le temps de faire le point avec le diagnostic interactif proposé par LEDIAG. Le premier diagnostic de l’atmosphère managériale d’une organisation qui prend en compte l’ensemble des facettes digital et télétravail.
Aucun commentaire