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 dont souffre les 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 maîtrise 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 a coûté quelque 125 millions de livres sterling à la société britannique. 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é à 217 millions de dollars, a dû être remboursé par AXA Rosenburg, ainsi qu’une pénalité imposée par la Security and Exchange Commission s’élevant elle à 25 millions de dollars supplémentaires. Nous pourrions également évoquer plusieurs études et sondages qui démontrent le faible taux de réussite de projets et l’insatisfaction croissante des clients.

La qualité en jeu

Simon Alexandre (CETIC): “Tout comme la dette financière qui augmente avec le temps si on ne maîtrise pas les remboursements, la dette technique augmente avec le temps si la qualité de l’application est négligée.”

Ces risques sont encore plus importants dans le contexte des PME en raison de la multitude d’arbitrages qui doivent être faits au quotidien, principalement dus aux limitations en ressources humaines 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 croître 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 maîtrise des risques. Or, il est notoire qu’il est impossible de gérer ce que nous ne pouvons pas mesurer.

Gérer des risques

S’appuyant sur sa propre unité de recherche qui travaille sur des analyses de code, le CETIC étudie depuis une décennie la problématique de la maîtrise des risques liés aux produits logiciels. 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.

Paradoxe. 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.

Ce concept n’est pas nouveau: c’est Ward Cunningham, en 1992, qui fut le premier à mettre en lumière la notion de la Dette Technique, qui se définit comme étant le coût de la non-qualité des applications. En d’autres termes, la Dette Technique est le coût associé à la maintenance corrective et à l’évolution de l’application quand des raccourcis sont pris par l’équipe de développement dans le design et la conception de l’application afin d’attendre les objectifs de temps et de budget du projet.

Tout comme la dette financière qui augmente avec le temps si on ne maîtrise pas les remboursements, la dette technique augmente avec le temps si la qualité de l’application est négligée.

Reprenons 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% du 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 cela risque de coûter cher à l’entreprise.

Maîtrise de la “dette”

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.

La Dette Technique est le coût associé à la maintenance corrective et à l’évolution de l’application quand des raccourcis sont pris par l’équipe de développement dans le design et la conception de l’application.

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 de 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 pris la forme de revues de code. A l’époque 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 connue sous le nom de SQuaRE). Cette méthodologie 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.

Maîtriser la Dette Technique du parc applicatif permet donc d’instaurer un dialogue entre le business et le département informatique. Ce qui, à son tour, permet d’aligner les visions des deux acteurs. Ceci permet également de mettre en évidence et de maîtriser des risques techniques qui se traduisent par des risques business et d’é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.