« ... et c'est sa seule définition. En faire plus que cela, ou ajouter des choses pour faire plaisir, c'est de la surqualité. Ça n'a pas d'intérêt, et ce doit être évité. »



C'est ainsi que les choses m'ont été présentées au cours d'une réunion avec ma direction technique, chez un ancien employeur.



Comment dire... Oui, mais non. En fait, ma direction technique confondait qualité et complexité du produit. Or si conserver le produit aussi peu complexe que possible est effectivement une bonne conduite à tenir, s'en tenir à l'appréciation du client pour définir la qualité du produit est une erreur assez lourde.



Pourquoi éviter les ajouts ? Pour des raisons de complexité fonctionnelle et technique, et pour des raisons contractuelles.



Il est clair qu'il faut éviter de réaliser pour des clients des fonctions non inscrites dans la spécification fonctionnelle du produit commandé. On peut parfois être tenté de le faire, en guise de cadeau ou de "geste"^[1], mais c'est une erreur.

Pourquoi ? Simplement car si ces fonctions ne sont pas définies formellement, elles n'en sont pas moins partie intégrante du produit livré une fois qu'elles ont été développées. Elles sont de ce fait couvertes par la garantie, et en cas de dysfonctionnement, c'est la responsabilité de l'entreprise que de les corriger. Cela coûte du temps, et est rendu d'autant plus difficile que l'absence de spécification rend floue la notion de bon fonctionnement. On parle donc de temps développeur, de temps de gestion de projet, et aussi de temps commercial dans les cas les moins favorables.



Outre cela, de telles fonctions, même anodines en apparence, peuvent poser de nombreux problèmes. Problèmes techniques du fait des conséquences de ces ajouts lors des évolutions futures, mais aussi problèmes fonctionnels. Je pense ainsi à un "mode prévisualisation" qui avait ainsi été réalisé sur un projet de back office d'intranet :



La spécification décrivait qu'une fois rempli un formulaire de saisie de contenu de type "articles" par l'utilisateur, celui-ci pouvait au choix abandonner ou valider son entrée. L'abandon le conduisait à l'étape précédente (la liste des "articles" et des actions associées, en l'occurrence), la validation le conduisait à la page de contenu en question, telle que publiée.



Une fonction non spécifiée avait été ajoutée à ce système : la prévisualisation. Elle était assez analogue à ce que l'on peut trouver sur les plateformes de blogs pour les billets et commentaires. Simple à réaliser, il ne nous avait coûté que quelques heures sur un projet de centaines de jours. Le client était ravi car il désirait cette fonction mais sans que celle-ci n'ait été spécifiée et intégrée au budget. Nous étions ravi également car à peu de frais nous avions renforcé la relation avec ce client que nous aimions bien du fait de sa récurrence et de ses qualités humaines trop rares dans le monde du service informatique...



Malheureusement, ce mode prévisualisation s'est révélé problématique lorsqu'il s'est agit de faire évoluer l'application. En effet, lors de la définition de la version suivante, il était maintenant entendu par le client que cette fonction devrait être applicable à tous les formulaires de saisie de contenus, et pas seulement aux articles. L'argument était que par spécification la gestion des formulaires de contenu obéissait aux mêmes règles quelque soit le type de contenu, et que par conséquent, cette fonction disponible pour les seuls "articles" aurait également due être applicable aux "offres d'emplois" et "annonces diverses". Le comportement de la version courante, en production, a dès lors été considéré par le client comme un dysfonctionnement ayant échappé à la recette. Royalement, le client nous a même indiqué que la mise en production valant recette il ne demandait pas réparation de ce manquement à la version courante, mais seulement à la version suivante.



L'interlocuteur client ayant changé^[2], il n'était pas possible de le prendre à témoin. Le flou généré par l'ajout de cette fonction non documentée avait donc profité au client, notre service commercial n'ayant - à juste titre à mon sens - pas souhaité contre-argumenter tandis que nous n'étions pas en position de force et que le coût engendré était supportable.

C'est pour éviter ce type d'embêtements qu'on dit toujours de ne jamais faire de cadeaux aux clients et de s'en tenir « à la spécification, rien qu'à la spécification, et à toute la spécification » (dites "je le jure")... Et en cela, oui, les propos de ma direction technique lors de la réunion évoquée au début de ce billet étaient fondés.



Pourquoi l'appréciation du produit par le client ne suffit-elle pas à évaluer la qualité du produit ? Parce que c'est nous qui le maintenons.



L'appréciation du produit par le client est basé sur différentes choses:

• les fonctions proposées et leur facilité d'emploi: bien que définies par le client, celui-ci les redécouvre lors de la livraison. Ses idées ont pris forme, pour ne pas dire vie, et c'est cette mise en situation réelle qu'il apprécie.^[3].
• les performances: plus c'est rapide plus c'est apprécié, surtout si l'on parle de systèmes interactifs.
• la robustesse: plus il observe de dysfonctionnement, moins le client apprécie le produit.
• le look: plus important que l'on pourrait le croire, le look de l'interface graphique permet de faire passer bien des choses... comme il peut au contraire ruiner l'appréciation d'un excellent produit.
• mais aussi, la relation qu'il a avec le fournisseur: un bon relationnel aide considérablement à faire accepter au client un produit imparfait. Au contraire, un mauvais relationnel lui fera rejeter un produit remplissant pourtant tous ses critères techniques d'appréciation.

Et c'est tout.



Le client ne prend pas en compte la maintenabilité du produit. Il ne prend pas non plus en compte sa portabilité, en cas de changement d'environnement. Il a raison, puisqu'il s'agit de choses purement techniques, transparentes pour lui, et qu'il n'est sauf exception pas en mesure d'évaluer.



Pourtant, ces paramètres doivent être pris en compte impérativement car ils conditionnent la faisabilité et le coût de toute modification future ou de tout changement de plateforme d'hébergement. Pour ne s'intéresser qu'à la maintenabilité, un produit mal ficelé, mal conçu, mal écrit, peut finalement tourner à force de correctifs, et ce au point de donner l'impression d'être "de bonne qualité". Mais alors, la moindre évolution ou correction devient un coûteux casse-tête. L'adhérence entre les différents modules constituant le produit est l'un problèmes de maintenabilité les plus courants. La propreté et la structure du code source en est un autre.^[4].



Je ne sais pas s'il est utile de donner un exemple ici, toute personne impliquée dans le processus de développement informatique ayant normalement déjà vu son lot de produits mal pensés ou mal construits.

Or présenter un devis prohibitif pour une modification bénigne n'est pas la meilleure façon d'être compétitif ni de travailller dans de bonnes conditions. Rater une date de livraison ou se voir refuser une recette pour cause d'anomalies nombreuses et sans solution non plus. Donc, si personne ne se préoccupe de la maintenabilité du produit, c'est à la MOE de le faire, ne serait-ce que pour se rendre service. Et si votre hiérarchie vous dit le contraire, vous pouvez toujours opiner du chef et acquiescer, mais gardez à l'esprit qu'elle a tort.



Sans aller jusqu'à suivre la norme ISO 9126 qui définit la qualité logicielle, ce qui serait dans la majorité des cas l'excès inverse de celui de mon ancienne direction technique, il est intéressant d'en avoir le sommaire à l'esprit et de s'en inspirer autant que raisonnablement possible. Rendez-vous service !



Ah... mon ancienne direction technique avait également ajouté « c'est ce que l'on apprend en école d'ingénieurs », à propos de sa définition de la qualité. J'ose croire qu'aucune école sérieuse n'oserait donner pareille leçon, mais je suis intéressé par vos témoignages !

---

Notes

[1]Parce que le client est un bon client, parce qu'on le connaît depuis longtemps après plusieurs projets conduits pour lui, parce que ce client là est courtois et que ce n'est pas le cas de tous, parce qu'il est organisé et ne vous impose pas de travailler dans l'urgence, parce qu'il est est de bonne foi, lui... bref, pour des tas de raisons.

[2]Inutile de préciser que nous y avons perdu au change, je suppose...

[3]Il est déjà arrivé qu'un client me dise "c'est génial ce que vous avez fait là" à propos d'une fonction qu'il avait lui-même défini. Lui rappeler que l'idée était de lui l'avait conduit à m'expliquer que c'était "génial de la voir en vrai" (sic).

[4]L'article "Plat de spaghetti" de Wikipédia illustre bien la chose.

---

Enregistrer un commentaire

Veuillez consulter les mentions légales.

if (!window.google || !google.friendconnect) {
document.write('' +
'');
}

if (!window.registeredBloggerCallbacks) {
window.registeredBloggerCallbacks = true;

gadgets.rpc.register('requestReload', function() {
document.location.reload();
});

gadgets.rpc.register('requestSignOut', function(siteId) {

google.friendconnect.container.openSocialSiteId = siteId;
google.friendconnect.requestSignOut();
});
}

function registerGetBlogUrls() {
gadgets.rpc.register('getBlogUrls', function() {
var holder = {};

holder.currentPost = "http://www.blogger.com/feeds/7674268088161916946/posts/default/7901845977363646937";

holder.currentComments = "http://www.blogger.com/feeds/7674268088161916946/7901845977363646937/comments/default";

holder.currentPostUrl = "";
holder.currentPostId = 7901845977363646937

holder.postFeed = "http://www.blogger.com/feeds/7674268088161916946/posts/default";

holder.commentFeed = "http://www.blogger.com/feeds/7674268088161916946/comments/default";

holder.currentBlogUrl = "http://sofiennerida.blogspot.com/";
holder.currentBlogId = "7674268088161916946";

return holder;
});
}

if (!window.registeredCommonBloggerCallbacks) {
window.registeredCommonBloggerCallbacks = true;

gadgets.rpc.register('resize_iframe', function(height) {
var el = document.getElementById(this['f']);
if (el) {
el.style.height = height + 'px';
}
});

gadgets.rpc.register('set_pref', function() {});

registerGetBlogUrls();
}

BLOG_CMT_createIframe('http://www.blogger.com/rpc_relay.html', '17004817052819583239');