Pilotage des développements : éviter le piège des indicateurs trop abstraits

Lorsque l’on parle de qualité logicielle, nombre d’articles recensent les bonnes pratiques et les processus de développement à mettre en œuvre pour éviter qu’une application ne s’enlise sous le poids de sa dette technique : identifier les composants à risque, réaliser des revues de code régulières, refactorer les artefacts complexes, corriger les violations de règles bloquantes ou critiques, etc. Mais peu de recommandations existent quant au projet en lui-même : car oui, la mise en place d’une solution de qualimétrie est un véritable projet, avec ses parties prenantes, ses étapes et ses pièges.

C’est pourquoi il paraissait intéressant de partager l’expertise de consultants et de synthétiser les bonnes pratiques sur le sujet, en mettant en lumière quelques pièges identifiés lors de projets de pilotage des développements. A commencer par le premier : déployer des indicateurs trop abstraits.

Piège #1 : Déployer des indicateurs trop abstraits

Comme dans tout projet de mesure ou de pilotage, les indicateurs revêtent un caractère stratégique, car ils concrétisent la démarche qualité. L’indicateur est l’un des principaux livrables, et les projets de gouvernance des développements ne dérogent pas à la règle, bien au contraire.
Dans ce contexte, le piège réside dans la tentation de vouloir représenter l’état de la qualité d’un artefact par un indicateur trop synthétique, conçu à partir d’informations de types différents, parfois contradictoires. En résumé, mal concevoir ses indicateurs qualité revient à déployer dans un tableau de bord une série de hiéroglyphes dont la signification n’a plus de sens, y compris pour leur propre auteur.
Quand on « tombe dans le piège », l’indicateur est le plus souvent exprimé sous forme d’une valeur non bornée, sans unité. Par exemple : votre projet a une note de qualité globale de 128, sa maintenabilité est de 72 et sa robustesse de 42.

Vous le comprendrez facilement, ces valeurs ne signifient pas grand-chose en dehors de leur contexte, et soulèvent rapidement des questions qui viendront souligner la mauvaise conception de vos indicateurs et affaiblira votre démarche qualité dès les premières phases du projet :

Un problème très probable d’interprétation et de communication entre les développeurs et le management,
Un indicateur mal compris est un indicateur peu adopté, voire rejeté,
L’outil produisant l’indicateur sera parfois remis en cause, contourné par des indicateurs « maison » : cette double lecture compromet alors le pilotage des développements et les arbitrages qui en découlent.

Ce qui se conçoit bien s’énonce clairement

La conception de vos indicateurs qualité est donc un point crucial de votre démarche qui nécessitera une attention toute particulière. A ce titre, elle doit reposer sur des bases claires, solides et indiscutables. C’est une des garanties pour que votre démarche qualité soit comprise, mise en œuvre, adoptée et améliorée de manière continue. N’oublions pas le rôle de l’indicateur : il doit permettre de mesurer avec plus ou moins de précision l’écart entre une situation et un objectif. Cet indicateur doit également vous aider à bâtir le plan d’actions correctrices nécessaires pour atteindre l’objectif fixé.
Prenons un exemple concret pour illustrer. Un de mes objectifs qualité pour mon application est qu’elle soit fiable en production :

Je vais donc m’assurer qu’elle soit facilement testable,
Je vais également vérifier qu’elle a été effectivement testée !

- Mon indicateur de fiabilité contiendra par exemple :

Des métriques de code renseignant sur la testabilité du code (complexité des méthodes, couplage entre les classes, etc.),
Des informations issues des tests unitaires et d’intégration, comme le taux de couverture de test du code (via des outils comme JaCoCo, Emma, Clover…),
Le résultat des campagnes de tests fonctionnels,
Pour compléter la vision du niveau de fiabilité de mon application, je pourrais également inclure dans mon indicateur les informations issues d’outils de test de montée en charge.
Car en effet, si mon application est destinée à servir plusieurs milliers d’utilisateurs simultanés, une indisponibilité causée par une performance dégradée sera perçue comme un manque de fiabilité.

Les caractéristiques d’un indicateur efficace

Sans entrer dans les détails des normes prévues à cet effet (NF X50 -171, ISO 9001:2008…), nous pouvons dire d’un indicateur qu’il est efficace, dès lors qu’il présente les caractéristiques suivantes :

Utilité et pertinence : En quoi l’information apportée par un indicateur est pertinente et nécessaire pour mesurer l’écart et atteindre mon objectif ?
Simplicité : un indicateur doit être facile à expliquer et simple à mettre en œuvre. Dire ce que l’on fait, faire ce l’on dit et le vérifier. Un indicateur doit alors indiquer si l’objectif est atteint ou non (cf. l’approche « Goal Question Metric » de Victor Basili).
Un indicateur doit être représentatif et doit être :

- Exhaustif : Un indicateur doit, dans l’idéal, être disponible pour tous les artefacts entrant dans le champ de l’analyse. C’est d’ailleurs l’une des caractéristiques permise notamment grâce aux outils d’analyse de code.
- Quantifiable : par exemple, le taux de couverture des tests, le nombre de défauts en production, le total de violations, l’écart aux délais de livraison initialement prévus, etc.
- Objectif : la mesure ne doit pas être sujette à polémique. Quid du nombre de ligne de code pour indiquer la volumétrie d’un logiciel : devons-nous compter les lignes blanches ? Les commentaires ? Uniquement les instructions compilées ? Le code généré doit-il être pris en compte dans la volumétrie ?
- Opérationnalité : Concevoir un indicateur « sur papier » est une chose, le déployer et le faire vivre avec des données réelles en est une autre. Bien souvent, les données nécessaires à son calcul sont de format différents, dans des outils divers, voire même n’existent pas pour certains artefacts. Il faudra donc s’assurer de la disponibilité et du caractère industrialisable de l’indicateur à grande échelle.

La Dette Technique : un indicateur pertinent, simple à mettre en place et directement opérationnel

Pour éviter de tomber dans le piège des indicateurs abstraits, et à la lumière des caractéristiques détaillés plus haut, les indicateurs de type « Dette Technique » nous semblent particulièrement adaptés pour débuter un projet de pilotage de la qualité des développements.
La dette technique est une métaphore initialement exprimée par Ward Cunningham en 1990. Il s’agit d’un emprunt, volontaire ou non, des parties prenantes d’un produit logiciel.
Cet emprunt (ex : décaler la livraison d’une fonctionnalité au sprint suivant, remettre à une release majeure la refonte du modèle d’architecture, etc.) impliquera forcément – tôt ou tard – le remboursement de cette dette avec des intérêts. Autrement dit, la fonctionnalité décalée (emprunt), qui coûterait 100 unités d’œuvre à délivrer à un instant T (capital), coûtera en réalité 100 + X (intérêts) unités d’œuvres à T+1. Et comme pour un crédit bancaire, plus la durée de l’emprunt est longue, plus les intérêts sont élevés.
Convaincus de l’intérêt de cette approche, nombres d’acteurs du domaine en ont implémenté la mesure, afin de pouvoir quantifier le montant de la dette technique d’une application, généralement exprimée en unité de temps.
Grâce à cette mesure, le concept de Dette Technique accède au rang des indicateurs privilégiés en devenant un véritable outil pour piloter les développements par la qualité.
Les avantages de choisir la dette technique comme premier indicateur de votre projet sont nombreux :

Utilité : la Dette Technique peut avoir un impact négatif sur l’agilité des équipes de développement et leur capacité d’innovation. Une Dette Technique élevée implique des efforts de maintenance corrective importants.
Simplicité de compréhension : du DSI jusqu’au développeur en passant par le DevOp, la dette technique, dès lors qu’elle est exprimée en unités d’œuvre, parle à tout le monde. Par exemple, pour répondre aux exigences de fiabilité définies pour mon application mobile, il faudra allouer 10 jours/homme pour remettre le projet en conformité.
Facilité de mise en œuvre : dans les modèles les plus simples, la dette technique est calculée en additionnant les charges des non conformités. Ainsi, les premiers essais de cet indicateur peuvent parfaitement tenir dans un tableur Excel.
Conciliation des visions techniques et managériales : l’indicateur étant exprimé en unité d’œuvre (heures, jours / homme ou devises), l’ensemble des parties prenantes dialoguent avec un référentiel commun. Les ambiguïtés générées par un indicateur abstrait sont évitées. Les équipes se concentrent alors sur les problèmes de qualité, plutôt que sur la définition de l’indicateur en lui-même !
Un indicateur naturellement orienté « plan d’actions » : c’est l’un des énormes avantages liés à la simplicité de l’indicateur de Dette Technique. Calculé à partir des éléments non conformes aux exigences, l’indicateur permet avec une extrême facilité d’identifier les actions à mener pour atteindre le niveau d’exigence souhaité et réduire ainsi la dette technique d’un projet de manière efficiente et objectivée.