Qualification de la demande client

De nombreuses méthodes, des processus plus ou moins agiles, des cycles de développement existent en ingénierie logicielle. On y trouve des étapes comme l’ingénierie des besoins, l’analyse fonctionnelle, l’analyse technique, l’écriture du code et les tests. Tous ont pour point de départ un objectif du client et, pour atteindre celui-ci, une stratégie d’informatisation. A partir du constat d’une situation de départ, les experts déterminent une solution qui, à travers un ensemble d’étapes, va permettre de faire évoluer le système d’information du client de manière à ce qu’il satisfasse à ses exigences. Celles-ci représentent donc à la fois le point de départ et d’arrivée du cycle. A ce titre elles nécessitent d’être traitées avec rigueur.

Les livres s’arrêtent généralement là où commence l’expérience de la relation avec le client. J’ai pu constater sur divers projets combien il est difficile de réaliser une ingénierie des besoins rigoureuse. Les obstacles qui se dressent sont nombreux : manque de temps, manque de compétence, objectif à atteindre flou, périmètre du développement à effectuer mal défini, changement rapide et important des besoins…

Un problème que j’ai pu constater régulièrement lors de ces projets est la difficulté, pour le client et le fournisseur, de s’entendre sur la qualification des demandes. J’entends par qualification le fait de considérer une demande comme une demande d’évolution, une demande de correction d’une anomalie ou une demande d’assistance technique.

Cet article présente une courte étude visant à répondre à cette problématique de qualification d’une demande. Elle est articulée en 4 parties. La première présente succintement deux méthodes de gestion de projet : le Cycle en V et une approche du processus Itératif et Incrémental. La deuxième partie explique comment on pourrait qualifier les demandes suivant la méthode choisie. La troisième partie expose les problématiques de qualification et de communication entre Maître d’Ouvrage (MOA) et Maître d’Œuvre (MOE). La quatrième aborde ce que j’estime être le vrai problème de qualification : l’identification d’anomalies.

Projet et Cycle de Vie

Afin de mieux présenter la problématique de qualification des demandes, il est nécessaire de présenter d’abord un survol de concepts de gestion de projet informatique. De nombreuses méthodes existent à l’heure actuelle. Depuis la plus stricte adoptant le « Cycle en V » à la plus agile « Xtreme Programming ». Je retiens dans cette étude deux méthodes ayant fait leur preuve et présentant des avantages et des inconvénients.

Le Cycle en V

Issu du monde industriel, le Cycle en V est le suivi d’un chemin rigide et strict dans lequel chaque étape ne peut être commencée que si la précédente a intégralement été accomplie. En l’occurrence la Conception détaillée ne pourra commencer qu’à partir du moment où l’intégralité des besoins spécifiés aura fait l’objet d’une Conception préliminaire. L’intégrité du développement rend obligatoire la désignation d’un interlocuteur unique à la fois chez le MOE et le MOA.

Très rigoureux, il oblige à un travail complet, précis et documenté à chaque étape sans laisser aucune place au doute. Il permet des planifications précises. Est conçu ce qui a été spécifié clairement, complètement et sans ambiguïté. La rigueur de ce processus est aussi son point faible. Il est hermétique aux changements de spécifications en cours de route dans les phases d’expérimentation, demande beaucoup de travail à chaque étape ainsi que beaucoup de temps pour obtenir un résultat visible. Le cycle en V se base sur l’idée que le contrat entre le MOE et le MOA contient un cahier des charges précis avec un planning détaillé.

Le Cycle en V n’est, à mon sens, pas adapté à la gestion d’un projet informatique. Le besoin exprimé évolue souvent en cours de développement ce qui n’est pas permis, ou du moins difficile à mettre en place, dans cette méthode.

Le cycle itératif et incrémental

D’autres techniques ont vu le jour, les méthodes Agiles. La plupart d’entre elles suivent un processus Itératif et Incrémental. Il n’est plus besoin de tout spécifier pour ensuite tout concevoir, tout coder… au niveau de l’ensemble du logiciel. Ce dernier est construit au fur et à mesure, chaque cycle fournissant une version plus aboutie que la précédente.

Son grand avantage est sa capacité d’adaptation à l’évolution du besoin. Si, lors d’une itération, une fonctionnalité a été codée sur la base de spécifications qui ont ensuite changé, la fonctionnalité pourra être adaptée à celles-ci lors d’une itération suivante. On comprend bien ici que cette méthode admet l’incomplétude, l’incertitude ou encore l’ambiguïté des spécifications dans la mesure où elle intègre dans son processus la complétion de celles-ci jusqu’à validation.

Les problèmes liés à cette méthode sont la difficulté de planifier à l’avance la livraison du logiciel final, le stress causé par l’incertitude des spécifications changeantes et le risque de manque de rigueur de la documentation.

L’intégrité du développement rend obligatoire la désignation d’un interlocuteur unique à la fois chez le MOE et le MOA, mais donne plus de flexibilité sur les intervenants à tout niveau.

Quel modèle choisir

En fin de compte la clef de voute du Cycle en V est la spécification, tandis que celle du cycle itératif et incrémental est l’adaptation. Dans un contexte industriel où le MOA peut spécifier de façon détaillée son besoin, choisir une méthode en V est adaptée. Par contre, lorsque le MOA ne peut arrêter des exigences fermes et définitives, ne serait-ce parce que le contexte change constamment, le cycle itératif et incrémental est le plus apte à répondre à sa demande.

Qualifier une demande

La qualification d’une demande dépend directement de la méthode de gestion de projet. En effet, la définition d’une Evolution, d’une Anomalie ou d’une Assistance varie. Dans un premier temps je vais poser les définitions ancrées dans les esprits issues du Cycle en V pour ensuite démontrer comment celles-ci varient lorsqu’on aborde une approche itérative et incrémentale.

Qualification dans le Cycle en V

La qualification d’une demande dans ce contexte de gestion de projet est très rigide et imperméable au changement. Pour résumer : toute nouvelle fonctionnalité ou amélioration d’une fonctionnalité existante est une évolution. Tout comportement d’une fonctionnalité qui n’entre pas dans le cadre de la lecture stricte des spécifications est une anomalie. Une assistance est une aide du MOE pour la mise en production et l’exploitation du produit.

Qualification dans le cycle itératif et incrémental

La qualification d’une demande dans ce contexte de gestion de projet est très souple pour faciliter l’adaptation au changement. Pour résumer : ce qui est demandé initialement peut tout à fait changer en cours de route et les spécifications sont affinées par itérations successives.

Problématiques de qualification

Comme expliqué ci-dessus, le Cycle en V est adapté aux projets de développement logiciel. Il reste cependant ancré dans les esprits. La conséquence directe est que l’adoption d’une méthode agile cause des soucis de communication entre MOA et MOE. En effet, le premier spécifie un premier niveau qu’il juge suffisant et fait évoluer ses besoins tout en exigeant un résultat sans faille. De son côté, l’autre estime pouvoir livrer une fonctionnalité perfectible tout en développant avec la rigueur que nécessite l’informatique.

Réussir une bonne communication entre MOE et MOA demande qu’une méthode soit sélectionnée et pleinement intégrée par les deux parties afin qu’il n’y ait pas de malentendu. Je présente ci-dessous quelques cas d’incompréhension, voire d’opposition, entre MOA et MOE consécutifs à ce manque de communication que j’ai constaté lors du projet.

La malheureuse évidence

Un problème récurrent se pose lorsqu’on ne produit que des spécifications sommaires destinées à être étendues ensuite : je la nomme la « malheureuse évidence ». Combien de fois un MOE s’est entendu dire « cette fonctionnalité est boguée, elle ne fait pas […], c’est pourtant évident qu’elle devrait le faire. » Et le MOE de répondre « cela n’avait pas été spécifié ». On voit bien là qu’il y a un mélange entre les deux conceptions, en V ou itérative et incrémentale. D’un côté le MOA fournit des spécifications succinctes dans lesquelles il a omis de mettre ce qui était pour lui évident. De son côté le MOE a implémenté les dites spécifications en se disant qu’elles seraient approfondies si nécessaire plus tard. Par contre le MOA semble exiger dès la première livraison une fonctionnalité complète qui, en plus, prend en compte ses besoins non exprimés. Ils ne pourront pas s’entendre, ils n’ont pas la même vision de ce que chacun attend de l’autre.

Ce n’est pas une correction, c’est une évolution

Prenons un cas concret. Le titre des pages du site internet livré, qui est affiché dans les onglets du navigateur, était loin d’être causant. On peut lire « Nouvelle Page ». Une demande de correction d’anomalie est faite par le MOA. Celui-ci voulait qu’à la place de ce faux titre apparaissent des informations issues de la page dont l’onglet dépend. Attention, pour bien situer le contexte il faut signaler que la demande n’est pas de mettre un titre statique à chaque page, mais bien d’avoir un titre qui change en fonction de la page. Le MOE réalise le travail et présente sa facture. En effet de son point de vue si le MOA avait simplement demandé un titre statique, il se trouvait dans un cas de correction d’anomalie. Comme, par contre, le titre devait être dynamique (comme indiquer le n° et le nom du client dont on visualisait la fiche), cela nécessitait un travail et devait être considéré comme une évolution. Le travail n’est malheureusement pas été accepté par le MOA, arguant du fait que c’est une correction d’anomalie et non une évolution.

Mais c’est dans la spécification…

L’incertitude d’un besoin est liée au vocabulaire. Celui-ci doit être précis. Prenons un exemple fictif : les spécifications d’une fonctionnalité de facturation mentionnent « la facture pourra être exportée sous divers formats de fichier comme, par exemple, .doc, .pdf ou encore .xls. ». Lorsque la dite fonctionnalité est livrée, le MOA réalise que « ce serait bien » que l’export puisse se faire aussi en .gif. Il rapporte donc sa demande au MOE en la qualifiant d’anomalie à corriger. En effet dans sa vision des choses la fonctionnalité devrait le faire puisque cela a été demandé : « être exportée sous divers formats de fichier ». Le MOE ne l’entend pas de cette oreille. Pour lui, il a reçu une exigence décrivant sommairement une fonctionnalité d’export avec quelques exemples. Il a implémenté l’architecture d’export et les trois types de fichiers indiqués. Dans sa vision des choses les spécifications correspondaient parfaitement à la vision itérative et incrémentale : « le MOA veut une fonctionnalité d’export et, pour le moment, ce doit être au moins un export en .doc, .pdf et .xls, la suite viendra plus tard, lorsqu’il aura affiné son besoin ».

Vers une solution

On constate, après ces quelques exemples, que la problématique de qualification des demandes est la conséquence d’un manque de communication entre les acteurs du projet et surtout un manque de règles déterminées dès les prémisses du projet. En effet, si MOE et MOA ne partagent pas la même compréhension du processus de développement, comment pourraient-ils communiquer efficacement. Enfin de compte le problème vient de la difficulté à identifier une véritable anomalie et des enjeux financiers qui se trouvent derrière cette problématique de qualification.

Une piste : un assouplissement des qualifications

Dans un contexte itératif et incrémental les plus gros avantages sont l’adaptabilité du produit et la vitesse de réaction. Celui-ci est livrable très vite par prototypage. A chaque itération un ensemble de fonctionnalités décrites plus ou moins précisément sont implémentées, améliorées, corrigées, voire totalement modifiées. Le MOA a le droit de revoir sa copie à tout moment et le MOE doit s’adapter. Par contre il a un devoir impératif qui est lié au droit précédemment exposé : celui d’assouplir sa définition des qualifications.

Par exemple si une fonctionnalité évidente pour le MOA n’a pas été implémentée : ce ne sera pas une anomalie. Cela indique que les spécifications, admises dès le départ comme incomplètes, doivent être approfondies, que si le MOA avait pensé à écrire ces demandes évidentes elles seraient déjà implémentées, mais que finalement ce n’est pas grave parce que c’est comme ça que le cycle itératif et incrémental fonctionne.

Autre exemple, si une fonctionnalité est livrée fonctionnelle mais incomplète : ce n’est pas une anomalie. Cela signifie que dans le temps imparti pour livrer cette fonctionnalité, toutes ses spécifications n’ont pas pu être implémentées. Si le temps l’avait permis, elles l’auraient toutes été. Le MOE doit jouer le jeu de la transparence et annoncer la couleur en indiquant, à son avis, quelles spécifications seront/sont implémentées. Cela permettra au MOA de savoir à quoi s’en tenir.

Oui mais, qu’est-ce qu’une anomalie finalement ?

Essayons une première définition : est qualifié d’anomalie tout dysfonctionnement d’une fonctionnalité qui a été implémentée dans le respect des spécifications fournies.

Un exemple : une fonctionnalité de génération de facture est implémentée. Trois choses attirent l’attention du MOA lors de la recette :

• le TTC calculé est faux
• seuls deux des trois taux de TVA sont disponibles
• rien ne permet d’imprimer directement la facture à partir de l’interface

Comment analyser ces remontées ?

• le premier élément est une anomalie. En effet le TTC doit être correct.

• le second s’avère faire l’objet d’une assistance. En effet il faut paramétrer via l’interface ce taux qui n’apparaît pas.

• le troisième est une évolution. Les spécifications indiquaient que la facture devait être imprimable et il s’avère que c’est le cas si on accède directement au fichier .pdf généré lors de l’enregistrement de la facture. Mais il n’était pas indiqué qu’elle devait l’être directement via l’interface. Peut-être était-ce une « malheureuse évidence », ou peut-être que la spécification mentionnait une notion d’export très large dans laquelle l’impression était sous entendue. Aucun problème, cette évolution sera intégrée dans la prochaine itération.

Une question de franchise

Finalement, la vraie question qu’il faut se poser lorsqu’on se retrouve à qualifier des demandes est : quelles sont les conséquences. La réponse est simple, voire même un peu directe : l’aspect financier. C’est une vérité incontournable. La correction d’une anomalie n’est généralement pas facturée tandis que les assistances et les évolutions le sont. Nul besoin de chercher plus loin. C’est de bonne guerre, le MOA préfèrera que les demandes sur lesquelles le doute existe soient qualifiées d’anomalies tandis que le MOE essayera d’obtenir le contraire. Chacun a son budget, chacun a des frais, chacun doit protéger son espace vital.