Les origines du mal

L’architecture des applications et son code source sont à la source de tous les maux d’une application. Ils représentent la structure interne, l’ADN de l’application, le constituant de systèmes toujours plus complexes. Pour une application donnée, on pourra toujours améliorer les aspects fonctionnels, voire la performance. Mais si les fondations et sous-bassements d’un système sont de médiocre qualité, cela se ressentira très vite : coûts de maintenance exorbitants, risques importants en particulier sur le traitement des données, piètre performance, application instable, graves problèmes de sécurité… autant de problématiques « business » prenant racine dans le « code source ».

Vertus et complexités de l’approche globale

Concernant les systèmes de gestion critiques pour la mission d’une entreprise, - un CRM ou un système de facturation chez un opérateur de télécommunication, un site web de e-commerce, un système de trading dans une banque, un front office de gestion d’assurés pour une compagnie d’assurance, etc., est-il suffisant d’analyser les morceaux de « code source » pris indépendamment les uns des autres, sans se préoccuper du contexte technique général du système ? CAST , leader de l’Application Intelligence appliquée à la qualité logicielle (la qualité structurelle, interne des logiciels de gestion), pense que…non.

Après avoir analysé des milliers d’applications aux architectures et technologies très variées, CAST estime que la qualité interne d’un système s’apprécie via une vue d’ensemble, une approche systémique. Cette approche permet d’obtenir une vue générale, puis de descendre jusque dans les plus petits détails en prenant en compte le contexte du programme ou de la fonction examinée. Ainsi, un même programme, un même « morceau de code » jugé comme ayant une bonne qualité d’un point de vue « syntaxique » dans un contexte donné, pourra être considéré comme dangereux dans un autre.

Dans certains cas donc, des analyseurs de code source syntaxique, mono-langage et donc qui ne sont pas à même de « comprendre » l’ensemble d’un système, vont « valider » un code alors qu’il est dangereux, ou inversement émettre une alerte sur un problème de syntaxe ou de style, là où l’erreur est justifiée par des raisons bien plus impérieuses qu’un simple problème de style. Certes, les discussions généralistes autour d’un code globalement mal écrit comportent bien des vertus, mais elles sont très loin d’être satisfaisantes.

Le syndrome du boulon de qualité

En outre, contrôler le code source, au niveau du composant, de façon locale, revient également, par analogie avec l’ingénierie mécanique, à dire qu’un boulon est de bonne « qualité » sans se préoccuper de savoir si c’est le boulon de fixation d’un système qui doit soulever la tour Eiffel ou… une bicyclette.

Résultats des courses ? Les développeurs coupent très vite ces correcteurs « qui ne comprennent rien » et cherchent à corriger à tort et à travers. Tandis que les managers, eux, sont dans l’impossibilité de faire face à des analyses globales remontant des milliers d’erreurs, les systèmes de contrôle ne sachant pas les aider à les décortiquer, les analyser et trier le bon grain de l’ivraie. 

Mieux se comprendre pour mieux coordonner

La qualité en effet ne peut s’apprécier qu’en fonction d’objectifs business. Apporte-t-on autant de soin à la construction d’un vélo jetable à 50 qu’à une rame de TGV, ou bien à une voiture low cost qu’à une formule 1 ou un véhicule haut de gamme ? C’est par le croisement de ces deux visions fondamentales, vision holistique d’un système d’une part, et mesure de la qualité par rapport à des objectifs business d’autre part, que doit s’apprécier la qualité interne d’un système applicatif.

Le premier objectif passe par des automates capables de comprendre non seulement le « code » d’un composant élémentaire, mais aussi les interactions de celui-ci avec ces centaines parfois milliers, d’autres composants de technologie identique, mais aussi de technologies différentes : de l’interface homme-machine (Web, Windows, etc.) à la base de données (SQL Server de Microsoft, PL/SQL d’oracle, SQL/PSM d’IBM…) en passant par la logique applicative (Java, C++, Cobol. etc.). On parlera dès lors de « qualité interne des applications », comme le soulignent Messieurs Le Loc’h et Baumann, et non pas seulement de qualité du code. Il est à noter ici que l’essentiel des problèmes ayant un impact immédiat sur le business (robustesse, sécurité, performance...) prend racine dans des problèmes de qualité applicative, et que la qualité du code est souvent à la source de problèmes de moindre importance.

Le second objectif implique la « traduction » d’un sabir incompréhensible par le manager. Il s’agit de traduire les décennies de recherche en qualité logicielle (ISO , SEI - Software Engineering Group, OMG - Object Management Group, bonnes pratiques sur les bases de données, les serveurs d’applications, les architectures logicielles, etc.) et les considérations techniques sur l’ingénierie logicielle, en quelque chose que le responsable du système saura comprendre, et dont il pourra suivre les progrès en respectant des objectifs de qualité définis en amont. C’est l’émergence des tableaux de bord qualité, décrite par les auteurs de l’article ALM de chez Microsoft.