La dette technique, qui correspond à prendre des raccourcis à court terme au détriment d’options plus stables à long terme, semble être un problème plus répandu aujourd’hui qu’il y a quelques années – avant 2020 plus précisément. Ce problème existe en réalité depuis des décennies, mais il est impossible de le voir ou de le mesurer.
Néanmoins, il est probable qu’il soit plus répandu aujourd’hui, la récente ruée vers le numérique stimulée par la pandémie de Covid-19 ayant entraîné une dette technique qui pourrait être plus imposante qu’elle ne l’a jamais été.
Pour corroborer ces hypothèses, une enquête publiée l’année dernière par Software AG révélait que 78 % des organisations ont accumulé davantage de dette technique pendant la pandémie.
Une dette technique de plus en plus présente
La dette technique suscite de plus en plus d’inquiétudes. Pour les cadres, la priorité reste bien sûr le problème des compétences, mais la dette technique arrive juste derrière. C’est ce que démontre une récente enquête menée par IDG/Foundry auprès de 400 cadres informatiques.
Une immense majorité des cadres interrogés, 86 %, estiment avoir été touchés par la dette technique au cours des 12 derniers mois. Les auteurs de l’enquête définissent la « dette technique » comme « la mesure du coût de retraitement d’une solution causé par le choix d’une solution facile, mais limitée ». Parmi les retombées de la dette technique, 43 % des interrogés citent la capacité limitée d’innover, 41 % la difficulté à respecter les accords de niveau de service et 37 % les pannes et les temps d’arrêt.
« Il semble que la dette technique accumulée au cours de la pandémie de Covid-19 va suivre les DSI pendant plusieurs années », note Keri Allan dans un post de janvier chez IDG. « Dans leur hâte de faire en sorte que leur entreprise puisse continuer à fonctionner, de nombreuses organisations se sont retrouvées avec des solutions technologiques mal adaptées ou inutilement complexes. » Et de préciser, en prenant l’exemple des « solutions rapides que de nombreuses entreprises ont adoptées », comme l’accélération de « l’adoption d’applications de productivité SaaS telles que Zoom, MS Teams, G-Suite ou Office 365 ». En outre, ajoute-t-elle, « la mise en œuvre du cloud à court terme a également conduit à ne pas toujours avoir le temps de choisir le bon type de solution pour ce service. Ce qui a pu conduire à des factures élevées inattendues, ou à un « choc du cloud ». »
Une dette dissimulée
Si les responsables informatiques semblent être conscients de cette surcharge, la dette technique n’est pourtant pas si facile à détecter. « Le problème est que la plupart du temps, la dette technique est secrète – un passif hors bilan inconnu et non défini », explique Wayne Sadin, analyste technologique, cité dans un article du Cutter Consortium.
Alors, quelle est la meilleure façon d’engager des ressources pour gérer la dette technique ? Il serait contre-productif de passer la majeure partie de son temps à essayer de réorganiser les systèmes et les solutions en place. Dans ce cas, le temps manquerait pour travailler à de nouvelles initiatives pour l’entreprise, et la dette technique se creuserait encore.
Dans cette perspective, un développeur chevronné du secteur des technologies a suggéré de ne pas consacrer plus de 25 % de son temps à la refonte et à la reconstruction des solutions les moins productives.
Comment démêler la dette ?
Mais comme pour tous les défis, il existe de nombreuses variantes de la dette technique. John DeWyze, développeur chez Shopify, propose donc d’appliquer la règle de 25 % à quatre niveaux de dette :
- La dette quotidienne : pour John DeWyze, il faut consacrer 10 % de son temps (4 heures par semaine) à la mise au point du code en cours de développement à ce moment précis. « Les ingénieurs devraient être autorisés et carrément encouragés à utiliser jusqu’à 4 heures par semaine s’ils veulent essayer d’améliorer le code dans un domaine qu’ils rencontrent, s’ils estiment qu’il en bénéficierait. »
- La dette hebdomadaire : c’est « la dette qui peut être résolue en ajoutant une carte ou un problème à un sprint », et les spécialistes devraient passer au moins 10 % de leur temps sur ce sujet également. « Pour prendre un exemple parlant, c’est comme si nous allions implémenter un nouveau code et que nous découvrons que nous avons une façon plus efficace ou plus propre de le faire. Nous pourrions même remanier un code adjacent pour utiliser notre nouveau code, ce qui simplifierait encore les choses et améliorerait nos API internes. »
- La dette mensuelle, ou annuelle : elle revient à revoir des projets, voire à y remédier. Les développeurs devraient y consacrer au moins 5 % de leur temps. Il s’agit d’une « dette qui prend des mois à rembourser », précise le spécialiste. La dette annuelle nécessite des réécritures, le genre de dette « où après de nombreuses conversations, quelqu’un conclut qu’une réécriture est la seule solution ». John Dewyze note que les 5 % annoncés reviennent « à des réunions de deux heures par semaine pour parler de la planification ».
La dette technique est un mal dont on entend beaucoup parler, mais peu d’organisations savent par où commencer pour la démêler. Parfois même, elles décident pour résoudre le problème de jeter leurs solutions actuelles et de repartir de zéro. Consacrer une partie du temps à démêler la dette – mais pas trop – peut au moins aider à trouver un bon équilibre.
Source : ZDNet.com
Cliquez ici pour lire l’article depuis sa source.