Le CETIC étudie depuis une décennie la problématique de la maîtrise des risques liés aux produits logiciels basée sur sa propre unité de recherche travaillant sur des analyses de code. Sur base de cette expertise accumulée, croisée avec de nombreuses études menées à travers le monde dans le domaine de qualité logicielle, la notion de la ’Dette Technique’ se dégage comme dénominateur commun au business et l’IT.
Pour respecter au mieux les contraintes du client (budget, temps, ampleur fonctionnelle du projet...) les équipes de développements doivent faire des compromis. Ces compromis impactent directement la qualité du design et du code du logiciel. Ils conduisent à des risques structurels et une augmentation significative des coûts de développement et de maintenance.
Le CETIC a mis au point une méthodologie d’évaluation des risques structurels des applications qui permet d’investiguer le degré de respect de standards de développement et l’alignement par rapport aux bonnes pratiques de l’ingénierie logicielle en matière de maintenabilité, d’évolutivité, de fiabilité et de performance des applications.
Sur base de ces indicateurs, la dette technologique peut être calculée et des actions prioritaires pour la maîtriser peuvent être identifiées.
Le parc applicatif d’une société privée ou publique est la base de sa chaîne de valeur ajoutée. Mais le contexte technologique, ainsi que le contexte business rendent extrêmement difficile la maintenance de cette chaîne de valeur sans encourir des risques business significatifs. Parmi les menaces de plus en plus fréquentes, citons : les retards de mise en production, l’indisponibilité des produits logiciels aux utilisateurs, la maîtrise de la sécurité de l’information, l’augmentation des coûts de développement et de maintenance.
Il est possible de citer plusieurs exemples où la faible maitrise de ces risques se traduit par des pannes ayant un impact financier mais aussi médiatique. Citons à titre d’exemple la panne du logiciel bancaire fabriqué par le groupe RBS Software qui coûté à la société Britannique quelques £125M. Ou encore les problèmes de qualité du logiciel du groupe AXA Rosenburg qui traite les transactions des investisseurs et gère leurs actifs. Malgré les plaintes de clients, rien n’avait été entrepris pour parer aux problèmes du logiciel dont les bugs ont causé des pertes aux clients de la société. Le montant de ses pertes estimé à $217m a du être remboursé par AXA Rosenburg, ainsi que une pénalité imposé par Security and Exchange Commission s’élevant elle à $25m supplémentaires. Nous pouvons également citer plusieurs études et sondages qui démontrent le faible taux de réussite de projets et insatisfaction croissante des clients.
Ces risques sont encore plus importants dans le contexte des PME à cause de multitude d’arbitrages qui doivent être faits au quotidien principalement dû aux limitations de ressources humains et financières. La pression exercée par le business sur le département informatique pour délivrer de nouvelles fonctionnalités afin de répondre aux demandes des clients et rester compétitif face à la concurrence se traduit par une détérioration de la qualité des logiciels délivrés. Cette vision commune de nos jours présente un paradoxe à sa source : la vision des projets informatiques est une vision tactique et donc par définition est une vision court terme. Cependant, les applications doivent supporter une stratégie de société qui elle est stratégique, donc long terme.
La conséquence de cette disparité dans les visions entre le business et l’informatique fait accroitre significativement les risques cités en début de cet article. De plus les deux parties n’ont pas un dénominateur commun qui permettrait une communication facile afin qu‘elles puissent élaborer une stratégie commune alignée sur la maitrise des risques. Et il est notoire qu’il est impossible de gérer ce que nous ne pouvons pas mesurer.
Le CETIC étudie depuis une décennie la problématique de la maîtrise des risques liés aux produits logiciels basée sur sa propre unité de recherche travaillant sur des analyses de code. Sur base de cette expertise accumulée, croisée avec de nombreuses études menées à travers le monde dans le domaine de qualité logicielle, la notion de la Dette Technique se dégage comme dénominateur commun au business et l’IT. Ce concept n’est pas nouveau : c’est Ward Cunningham en 1992 qui était le premier à mettre en lumière la notion de la Dette Technique qui se définit comme étant le coup de la non qualité des applications. En d’autres termes, la Dette Technique est le coût associé à la maintenance corrective et évolution de l’application quand des raccourcis sont pris par l’équipe de développement dans le design et conception de l’application afin d’attendre des objectifs de temps et budget du projet. Tout comme la dette financière qui augmente avec le temps si on ne maitrise pas les remboursements, la dette technique augmente avec le temps si la qualité de l’application est négligée.
En reprenant l’exemple d’une PME dans son contexte d’arbitrage des ressources, en début de projet elle se concentre sur l’ajout des fonctionnalités à valeur ajoutée au produit. Vu les arbitrages des ressources, la société délivre plus de fonctionnalités (90% temps) au détriment de la qualité du code produit. Mais au fil de temps le besoin de la maintenance corrective se fait sentir : les ajouts de nouvelles fonctionnalités prennent beaucoup plus de temps, il y a du retard dans le planning, le budget est dépassé. La majorité des ressources est consacrée à la maintenance corrective. Ceci est le prix du remboursement tardif de la Dette Technique. Au plus loin on repousse un suivi de la qualité d’un produit logiciel au plus cher ça risque de couter à l’entreprise.
La maîtrise des risques applicatifs et de la Dette Technique ne se limite pas au contrôle de la qualité fonctionnelle (ce que l’application est censée faire au niveau métier) et non-fonctionnelle (mesure de la performance, disponibilité, fiabilité,…) du code. Il est également crucial de mettre le code en perspective avec les phases amont (conception, exigences) et aval (intégration, test, maintenance) et tout particulièrement d’avoir la maîtrise de la qualité structurelle de l’application, c’est-à-dire la qualité de son architecture ainsi que de la forme même du code (niveau de documentation, respect des conventions de codages,…).
La façon historique de gérer la qualité structurelle a été des revues de code. Dans le temps des applications monolithiques mono-technologie, cette approche avait un sens. Aujourd’hui il n’est quasiment plus possible de justifier une revue de 1% d’une application et une extrapolation statistique sur les 99% du code restant sur des projets multi-technologies.
Heureusement des outils supportant un niveau élevé d’automatisation sont largement disponibles pour la plupart des technologies. Leur mise en œuvre nécessite cependant une expertise spécifique. C’est dans ce contexte que le CETIC a mis au point une méthodologie d’évaluation des risques structurels des applications qui trouve ses sources dans la norme ISO9126 (aujourd’hui approfondie dans la norme ISO25000, aussi connu sous le nom SQuaRE) et qui permet d’investiguer le degré de respect de standards de développement et l’alignement par rapport aux bonnes pratiques de l’ingénierie logicielle en matière de maintenabilité, évolutivité, fiabilité et performance des applications. Sur base de ces indicateurs, la dette technologique peut être calculée et des actions prioritaires pour la maîtriser peuvent être identifiées.
Maitriser la Dette Technique du parc applicatif permet donc d’instaurer un dialogue entre le business et le département informatique ce qui en son tour permet d’aligner les visions des deux acteurs. Ceci permet également de mettre en évidence et maitriser des risques techniques qui se traduisent par des risques business et éviter le paiement trop tardif de la Dette Technique qui souvent coûte beaucoup trop cher. C’est ainsi que le département informatique pourra pleinement exécuter son rôle de support au business.
Le contenu de cet article a été publié sur le site d’informations Regional-IT - "Simon Alexandre (CETIC) : gare à la ’dette technique’ des solutions informatiques".
N’hésitez pas à nous contacter mailto:business@cetic.be, pour plus de détails à propos de la Dette Technique.