01 53 63 37 87

certification PMI

Article Delf

La « Recette fonctionnelle » fonctionne t elle ?

consulting formations PMP® simulateur PMP®

La « Recette fonctionnelle » fonctionne t elle ?

Un article de  Mauricette Fonctionnelle

A cette question existentielle, il nous faut répondre « NON !!! » ou « MAL ! ». Mais pourquoi ?

Depuis les débuts de l’informatisation de la gestion des entreprises, il aura fallu une quinzaine d’années pour que l’on utilise des méthodes de conception, vingt ans pour que l’on envisage un fonctionnement de type client fournisseur (maîtrise d’ouvrage / maîtrise d’oeuvre), etc…

Combien d’années encore avant de résoudre les problèmes de recette fonctionnelle ? Nous n’avons pas la prétention de présenter ici « THE » méthode qui va résoudre tous vos problèmes, mais nous vous proposons ici des éléments de réflexion et les principales erreurs que nous avons rencontré au cours de nos nombreuses interventions.

« A QUOI SERT LA RECETTE, DANS LA MESURE OÙ LE LOGICIEL A DÉJÀ ÉTÉ TESTÉ PAR LES INFORMATICIENS ? »


Il ne servirait pas à grand chose de vouloir refaire le travail du réalisateur qui rappelons le, doit livrer un produit réputé fonctionner. Par ailleurs, le « recetteur » n’a pas les moyens d’exécuter des tests de fonctionnement dans la mesure où il n’a à sa disposition que l’exécutable.

En revanche, le maître d’ouvrage aurait avantage à s’assurer que les tests de fonctionnement ont bien été réalisés (comment ? c’est une autre histoire !!!). La recette est la pierre angulaire de l’approche contractuelle de la réalisation des logiciels. L’approche contractuelle de la production informatique, s’est matérialisée par la séparation des responsabilités entre la maîtrise d’ouvrage (le client) et la maîtrise d’oeuvre (le fournisseur). Toute relation contractuelle se fonde sur un triptyque incontournable :

  1. la signature d’un contrat (contrat commercial en cas de sous traitance, contrat de service en interne).
  2. Le contrôle de la conformité du logiciel livré (c’est la recette).
  3. Le paiement des travaux (facturation externe ou interne, règlement budgétaire, etc.).


« QUELLE EST LA RÉFÉRENCE DE LA RECETTE FONCTIONNELLE » ?

Tester sans référence ? Est-ce possible ? Est-ce contractuel ? Les tests sans références existent, mais sont rares il s’agit :

  • soit des tests « destructeurs » qui ont comme objectif de vérifier la robustesse des logiciels,
  • soit de l’expérimentation qui sert à vérifier que les utilisateurs finaux peuvent travailler correctement avec le nouveau logiciel.

En aucun cas ces tests ne remplacent la recette fonctionnelle, en revanche ils sont (ou peuvent être) complémentaires. La recette fonctionnelle s’insère dans une logique de contrôle de conformité. Rappelons les différentes étapes des contrôles de conformité.

  1. Le maître d’ouvrage (le client) exprime le besoin dans un document que l’ont a coutume d’appeler « cahier des charges ». Rappelons ici que le maître d’ouvrage n’est pas l’utilisateur du futur produit, mais un « professionnel ». D’une manière ou d’une autre, ce cahier des charges est soumis à des contrôles de conformité au cours de son élaboration par les groupes utilisateurs et par des comités de décideurs (comités de pilotage). Le cahier des charges engage contractuellement le client sur son besoin.
  2. Une fois sélectionné, le maître d’oeuvre (interne ou externe) propose une « solution détaillée » (spécifications fonctionnelles détaillées, spécifications externes, etc..). Ces spécifications doivent être formellement validées par le maître d’ouvrage. La référence de cette validation est le cahier des charges. Les utilisateurs finaux sont aussi concernés par cette validation pour s’assurer du réalisme de la solution détaillée proposée. Les spécifications externes validées engagent contractuellement le client et le fournisseur sur le contenu du futur produit. 3. Le maître d’oeuvre réalise le produit spécifié le teste et le livre.

Le maître d’ouvrage effectue alors la recette fonctionnelle par référence avec les spécifications externes validées. Le logiciel livré doit être conforme aux spécifications validées.

Le maître d’ouvrage ne peut pas exiger que des fonctionnalités absentes des spécifications soient ajoutées et « a contrario » le maître d’oeuvre doit remettre en conformité si des manques sont constatés par rapport aux spécifications.

La référence de la recette fonctionnelle est donc le dossier de spécifications fonctionnelles détaillées VALIDEES. Ce préalable est indispensable, en l’absence de ce document, la recette est impossible et on se retrouve dans une spirale d’arrangements et de marchandages proche de la logique d’achat en vigueur dans les souks orientaux.

« LES UTILISATEURS FINAUX PEUVENT-ILS PARTICIPER À LA RECETTE FONCTIONNELLE ? »

Oui mais pas n’importe comment. On rencontre de nombreuses maîtrises d’ouvrage qui confient aux utilisateurs finaux la recette fonctionnelle sous prétexte que ce sont eux qui ont la maîtrise du métier. Sans précaution, ceci peut se révéler catastrophique ou au moins difficile. Pourquoi ?

  1. Le produit livré n’est pas terminé et peut encore comporter des anomalies que la recette a comme objectif de détecter. Ces anomalies « résiduelles » (sic !) peuvent désarçonner l’utilisateur, renforcer sa méfiance à l’égard du produit et en conséquence aggraver sa réticence naturelle au changement.
  2. En agissant ainsi on fait une confusion entre
  • « recette » qui consiste uniquement à vérifier la conformité par rapport aux spécifications et
  • l’expérimentation qui a pour but de vérifier l’adéquation entre le logiciel et son usage au quotidien.

En revanche, dans une recette structurée, les utilisateurs peuvent participer à la préparation de la recette qui consiste à réaliser les « cahiers de recette » ( procédure de recette, cas de recette et base de recette) pour monter des cas réalistes, mais il est a déconseiller qu’ils participent à l’exécution de la recette qui consiste uniquement à passer les cas de tests, à détecter les anomalies, à les décrire, à suivre les corrections et à gérer la non régression.


« ET PUIS, …… »

La rédaction d’un article est soumis à des contraintes et notamment à des contraintes de longueur…. J’arrive au bout de l’espace qui m’était imparti et il me restait plein de sujet à aborder comme :

  • La « recette » dans le cas d’intégration de progiciel.
  • La recette dans l’application des méthodes AGILES.
  • Recette et approche itérative.
  • L’organisation de la recette.
  • Recette et garantie ?
  • Etc.

Ces différents sujets feront probablement l’objet de prochains articles mais en attendant vous pouvez me contacter à
par email via le formulaire de contact du site à l’attention de Bernard Leblanc. (A suivre …)