Une enquête révèle que la dette technique a un impact sur la capacité d’innovation de près de 70 % des entreprises. En l’absence d’une observabilité architecturale continue, il est courant de déployer un nouveau code et de… voir surgir des problèmes inattendus.

Menée par le cabinet de conseil Protiviti auprès de plus de 1 000 cadres du secteur technologique dans le monde entier, cette étude constatait un paradoxe. Une forte majorité (79 %) des organisations a défini des objectifs.

Mais seuls 54 % d’entre elles étaient en mesure de présenter une stratégie de réduction de la dette. Il n’est donc pas vraiment étonnant d’apprendre que 79 % des projets de modernisation de logiciels échouent.

Évaluer l’architecture

Ce constat n’est peut être pas si étonnant que ça, car il est difficile de quantifier le processus d’innovation. Par exemple, les organisations qui ont répondu à l’enquête y investissent un tiers (31 %) de leur budget informatique et consacrent 21 % de leurs ressources informatiques à la seule gestion des systèmes existants.

Mais quelle part de ce même budget est consacrée à l’innovation des technologies de base existantes ou à l’émergence de nouvelles technologies ?

De nombreuses raisons ont été avancées pour expliquer l’échec des projets. Ces raisons vont du manque de soutien de la direction à l’élimination de la collaboration en personne.

La plupart des équipes évaluent la dette technique en examinant la qualité du code, les ratios de défauts ou les ratios de dette technique d’une application. Elles évaluent rarement l’architecture d’une application, pensant qu’elle se résoudra d’elle-même au fur et à mesure de la modernisation. Si l’on ajoute à cette attitude les exigences de la livraison continue, la dérive architecturale s’accroît à chaque cycle de livraison.

« Plutôt que d’ignorer les préoccupations architecturales, les équipes de développement devraient se faire les championnes de l’observabilité architecturale continue », note Protiviti.

Migration vers le« cloud-first »

« Si l’architecture microservices présente de nombreux avantages, son réseau accroît la complexité de l’application. Chaque service est autonome. Si un microservice a besoin d’une ressource externe, il en fait la demande. Parfois, les développeurs écrivent du code supplémentaire pour maintenir l’indépendance des services, ce qui peut contribuer à la dérive architecturale », lit-on dans ce rapport.

La nature distribuée des applications microservices complique également les tests et le dépannage. Enfin, le cloud ajoute une troisième composante à la complexité des applications.

La principale priorité des entreprises au cours des trois prochaines années sera de moderniser et d’intégrer les applications aux services dans le cloud. Si la plupart des entreprises opèrent dans un cloud public, 55 % d’entre elles utilisent encore des systèmes sur site.

Au final, les développeurs doivent évaluer la viabilité de leurs applications au fur et à mesure qu’ils migrent vers une entreprise « cloudfirst ».