Comment assurer la qualité des logiciels développés en toute transparence ?

La qualité est peu considérée comme une appréciation absolue d'un service fourni.

Elle dépend de celui qui en parle et/ou qui la produit et la vision est bien souvent parcellaire ou partie prenante, que l'on soit client, manager, directeur de projet, chef de projet, expert technique, développeur, ou bien testeur. Dans un monde alternatif où le client exigerait la preuve que nous délivrons la qualité promise, comment procéderions-nous ?

La qualité, un concept encore mal abordé

Si je propose ce sujet, c'est parce que l'organisation économique dans son intégralité est concernée : la qualité est une affaire partagée et portée par tous. Dans l’idéal, les différents intervenants accomplissent des actions pouvant être mesurées et justifiées (une action doit générer de la valeur impliquant de la qualité). L’ensemble des données mesurables doit être communiqué. L’interprétation ne se fait que par une instance transverse afin d’écarter le risque de perte de données et donc d’information.

Bien souvent dans le but d’imposer des normes et de transformer chaque entité de l’entreprise en unité de rentabilité indépendante, l’entreprise agrège des données pour en faire des indicateurs et perd donc de l’information qui serait pourtant bien utile à la prise de décision. Elle perd évidemment de la transparence tout en pensant faire le contraire. Dès lors qu’une organisation ne se pense plus comme un seul et même système, avançant l’idée selon laquelle tout acteur doit être rentable unitairement, il en résulte la déresponsabilisation puis la méconnaissance, voire l’ignorance de la raison d’être de chaque composante du système.

La qualité n’est donc plus envisagée comme une vue d’ensemble mais une agrégation d’indicateurs de données déjà agrégées, ce qui ne donne pas le même résultat ou pas ... Les indicateurs indiquent, ils ne sont pas porteurs de compréhension, nous devons faire ce travail. Il faut donc définir et partager une méthode de lecture des indicateurs.  

Des outils, mais pas que ...

Quand je parle de qualité, il ne s'agit pas essentiellement de s'intéresser à des indicateurs fournis par des outils sur l'étagère, aussi bien soient-ils. Nous possédons tous des outils de mesure de la qualité du code produit, est-ce que cela suffit à définir notre métier ? Un client nous confie un parc applicatif en MCO (maintien en conditions opérationnelles) ; comment lui prouver que nous garantissons la qualité des livrables alors que le turnover s’envole dans les entreprises (rivalisant par ailleurs comme jamais pour attirer les talents), entraînant une dissémination de la documentation ?

Par ailleurs, la qualité n'est qu'un mot qui n'implique pas l'effort à fournir. Il est primordial de définir les exigences nécessaires pour atteindre la qualité ciblée. Un taux de duplication bas et une couverture de code à 100% ne suffisent pas à démontrer que nous délivrons de la qualité. Il faut comprendre ces indicateurs et les expliciter au client, mais cela ne suffit pas. Nos démarches d'amélioration continue, d'élévation du niveau d'autonomie (revues, formation, workshop, ...), d'innovation et de documentation sont assurément des actions démontrant une démarche orientée qualité.  

Responsabilités & limites

La qualité est, selon moi, une culture qui doit se pratiquer à chaque instant. Chaque collaborateur est le garant de ce qu'il produit, en fonction de sa perception, son niveau de conscience et d'autonomie. Il ne s’agit pas de proposer à chaque collaborateur une méthode prônant l’amélioration continue tout en rajoutant des actions supplémentaires. Nous atteignons aujourd’hui un niveau important d’interactions, rajoutant des rôles, des responsables sans visibilité sur l’impact réel sur la qualité.

Il faut faire attention à la surcharge pondérale d’un système privilégiant la mise en place de contrôle aux moyens d’assurer la qualité, le contrôle étant axé sur le curatif engendrant des surcoûts importants à cause du retard de détection. La proactivité et la prévention sont des axes à privilégier, mais ils nécessitent l’anticipation, cet effort étant bien plus lourd, a priori, que de réagir à posteriori, ce qui est un calcul court-termiste. Cependant, les responsabilités sont différentes, certains doivent respecter des normes de développement, d'autres doivent les définir, ou donner les moyens de les appliquer. Comment donner les moyens d'atteindre la qualité promise ? Comment faut-il comprendre les besoins et s'approprier l'expertise du métier ?

C'est un problème essentiel qui se pose à un manager. Il détient les moyens financiers, donc de décision, et peut avoir une conscience parcellaire des besoins opérationnels. Quelle est la maturité d'un client qui exige la qualité d'un service alors qu'il pondère majoritairement le prix lors d'un appel d'offre ? Est-ce qu'il ne devrait pas plutôt définir un ensemble de métriques au-delà du code (l'exemple type serait la synthèse trop restrictive d'un tableau de bord SonarQube) ? La qualité démontre également du niveau de confiance que nous estimons avoir atteint dans le résultat obtenu.

Cela passe aussi par notre capacité à démontrer chaque élément de nos réponses. Que penser d'un engagement contractuel (ex : SLA - Service Level Agreement - de temps de réponse, résolution et contournement d'anomalie) si nous ne sommes pas capables de mesurer chaque phase de nos process ? Tout choix doit être formalisé et pouvoir être expliqué sous toute forme que ce soit (documentation, code, prototype, tests, ...), ce qui augmente notre capacité à démontrer la maîtrise de nos actions.  

Perspectives

Le client est le meilleur garant de la qualité que nous délivrons ; augmenter sa maturité et son implication peut nous donner un levier intéressant. Nous nous élevons d'autant plus lorsque nous sommes contraints, tant que les intentions sont vertueuses. Il existe des exemples où le client impose des normes de développement. C'est une démarche plutôt positive donnant le gage d'une maturité et d'un engagement fort, toutefois bien souvent contrebalancé quand le mieux disant est choisi.

Un autre enjeu est de limiter les empilements hiérarchiques pour privilégier la transversalité, c’est-à-dire aplatir les organisations. Trop de distance entre les acteurs nuit à la prise de conscience des enjeux de chacun et diminue la maîtrise des indicateurs. Prenons en exemple des mouvements auto-organisés (ex : DevOps) dont la prise en compte des enjeux au-delà de soi fait partie du manifeste. Prendre en compte les difficultés et les problématiques des acteurs avec lesquels nous interagissons nous enrichit et augmente notre compréhension : notre niveau de conscience du monde s’élève mais tout cela a besoin de transparence.  

Conclusion

Cette réflexion mériterait d’être bien plus longue ; le secteur du développement logiciel cherche des pistes tous azimuts pour améliorer sa capacité à répondre aux demandes du client, l’ensemble des méthodes qui pleuvent depuis plusieurs années maintenant en est la preuve. Les nouvelles organisations étant moins verticales et plus horizontales ou matricielles se dotent de moyens de communication plus complexes et diffusent plus d’informations, ce qui participe à l’augmentation de la transparence.