La recette

12 décembre 2002

La « recette », c’est l’opération par laquelle le client reconnaît que le produit livré par le fournisseur est conforme à la commande passée, qu’il est exploitable dans le système d’information de l’entreprise, et enfin qu’il est opportun de le mettre à la disposition des utilisateurs.

La recette est réalisée selon des procédures qui ne s’improvisent pas. Elle comporte plusieurs étapes. Enfin, elle présente des risques.

Le cahier de recette

La théorie de l’informatique, confirmée d’ailleurs par la pratique, enseigne qu’il est impossible de prouver qu’un logiciel ne comporte aucune erreur (voir « Petit résumé du théorème de Gödel »). La procédure de recette ne peut donc pas être exhaustive : quel que soit le soin que l’on apporte à la définition des tests qu’elle comporte, on n’aura jamais la certitude que le logiciel ne comporte aucune bogue.

On peut toutefois, et cela relève du bon sens, vérifier qu’il remplit correctement les fonctions essentielles que l’on attend de lui que ce soit en termes de performances, de qualité des données ou d’interface homme-machine. La liste des tests à réaliser doit être établie à froid, avant la livraison du produit ; elle porte le nom de « cahier de recette ».

La combinatoire des tests possibles étant infinie, le cahier de recette constitue une sélection au sein de cette combinatoire. Certains tests sont coûteux en raison de la volumétrie ou des difficultés techniques qu’ils impliquent. Comme le budget accordé à la recette est limité, le cahier de recette doit idéalement comporter la liste de tests la plus efficace pour un coût donné.

Il faut que la recette soit effectuée en partant de « vraies données » et non de données de qualité parfaite. On sait en effet qu’en informatique de gestion les données sont souvent, pour des raisons parfaitement compréhensibles (voir « Articuler l'ordinateur et l'être humain »), de mauvaise qualité (codages imparfaits, données manquantes, vérifications négligées). C’est par rapport à cet état de fait qu’il faut évaluer la qualité de l’opération, et non par rapport au monde idéal où les données seraient sans défauts.

Il faut préciser le protocole selon lequel la recette sera organisée : quelles seront les tâches qui incomberont au client, celles qui incomberont au fournisseur ; quels seront les documents qu’ils devront se communiquer ; dans quel ordre les tests seront réalisés ; quels seront les seuils d’acceptation du produit. Si le protocole n’est pas défini à l’avance, le risque de conflits ou à tout le moins de malentendus entre client et fournisseur sera élevé.

Les recettes

On distingue deux étapes dans la recette : la « recette usine », faite avant la livraison du produit par le fournisseur, permet à celui-ci de vérifier que le produit est conforme à la commande reçue ; la « recette utilisateur » est faite par le client après livraison.

Il faut que le compte rendu de la recette usine soit livré par le fournisseur en même temps que le produit : ce compte rendu apportera au client la preuve que le produit a été sérieusement testé avant sa livraison, et permettra de gagner du temps en ne refaisant pas les tests déjà réalisés par le fournisseur. Il faut prévoir la livraison du compte rendu de la recette usine dans le protocole de recette, sans quoi le client aura du mal à l’obtenir.

La recette utilisateur comporte deux étapes :

-          une recette technique, réalisée par la direction informatique du client, vérifie que le produit est exploitable sur la plate-forme informatique de l’entreprise (compatibilité avec ses matériels, systèmes d’exploitation et logiciels) et que la performance physique est acceptable (volumétrie des bases de donnée et des flux de messages, délais d’affichage sur les écrans des utilisateurs, robustesse en exploitation) ;

-          une recette fonctionnelle, réalisée par la maîtrise d’ouvrage, vérifie que le produit fournit les fonctionnalités demandées par le cahier des charges et qu’il est acceptable par les utilisateurs.

Les tests détectent des anomalies ; chaque anomalie fait l’objet d’une « fiche d’anomalie » envoyée au fournisseur. Celui-ci corrige les anomalies jusqu’à convergence des tests. Il arrive parfois que la correction d’une anomalie provoque d’autres anomalies, ce qui peut obliger à refaire des tests qui avaient auparavant donné un résultat acceptable.

Il est normal, inévitable qu’un logiciel d’une certaine importance contienne des erreurs : la détection d’anomalies au début de la recette n’a donc rien de scandaleux même si elle suscite toujours une tension entre client et fournisseur. Le véritable critère de qualité réside dans le délai de correction des anomalies : si ce délai est long, si les corrections suscitent d’autres anomalies de telle sorte que le nombre d’anomalies à traiter ne diminue pas, le client doit s’interroger sur la qualité du logiciel et sur son évolutivité.

Les vérifications

Lorsque les tests de recette ont convergé, le client prononce une « vérification d’aptitude » (VA). Il est d’usage que le fournisseur facture à ce moment là 80 à 90 % du prix du produit (mais non la totalité, car il reste du travail à faire). Puis le produit est mis en exploitation sur un site pilote.

On détectera alors d’autres anomalies, puisque le cahier de recettes ne pouvait pas être exhaustif. Elles devront elles aussi être corrigées. La convergence de ces corrections peut demander quelques mois.

Une fois les anomalies détectées sur le site pilote corrigées le client prononce la « vérification de service régulier » (VSR), ce qui permet au fournisseur de facturer le solde du prix du produit. Le produit peut alors être déployé sur tous les sites de l’entreprise, et l'on passe à l’étape du déploiement.

Risques

Toute recette présente des risques. La liste des tests que comporte le cahier de recette est inévitablement limitée : certaines anomalies n’apparaîtront donc que lors du site pilote. Il est donc préférable que le délai entre la vérification d’aptitude et la mise en exploitation soit court : si le produit est de grande taille, et livré sous forme de lots successifs, on s’efforcera de définir ces lots de sorte que chacun soit un « module exploitable », qu’il soit possible de le mettre en exploitation sur un site pilote dès sa livraison afin d’éviter l’« effet tunnel » qui se produit lorsque la mise en exploitation ne peut se faire qu'après la réception de l'ensemble des divers lots.

Il convient, lors de l’élaboration du cahier de recette, de ne pas trop hiérarchiser les tests : on risquerait de bloquer longtemps certains tests en l’attente de la correction des anomalies détectées en amont.

Le délai nécessaire à la convergence des tests est aléatoire : on ne peut pas évaluer a priori la difficulté des corrections. Il faudra gérer la crise entre client et fournisseur quand ce délai semble s’allonger indéfiniment : cette crise peut aboutir soit (finalement) à une livraison de qualité acceptable, soit au refus du produit.

Enfin la recette est toujours pour le client un moment délicat, puisque le produit qu’il découvre résulte à la fois des spécifications qu’il a fournies et de la réalisation bâtie par le fournisseur sur la base de ces spécifications. Certaines des fiches d’anomalie seront interprétées par le fournisseur comme des demandes d’évolution et il demandera pour les corriger une rallonge au contrat. Il en résultera des négociations lors desquelles la relation entre client et fournisseur risque de se détériorer.