Focus sur la recette

Quand un projet de développement informatique se termine, vient l'heure de la recette. La "recette" c'est une période de test fonctionnel et technique qui doit valider la bonne réalisation et la bonne conformité de ce qui est développé avec ce qui est spécifié et attendu. C'est une étape indispensable pour confirmer que ce qui est réalisé est correct, ou pas.

A lire : la rubrique "Les étapes du projet"

La recette c'est pas simple

Tester une application est une tâche plus compliquée qu'il n'y paraît. Contrairement à ce que m'avait expliqué mon peu glorieux maître de stage en 1992, ça ne consiste pas à taper comme un âne sur toutes les touches, n'importe comment, pour voir ce qui se passe.

Il faut vérifier un nombre important de paramètres qui peuvent aller du simple respect de la charte graphique à des considérations fonctionnelles très complexes.

Et ne pensez pas que les aspects graphiques sont mineurs : ce sont les premières choses que vos utilisateurs verront et les premières remarques qu'ils vous feront. C'est même sur cet aspect qu'ils vont porter leur premier jugement de votre application et décréter si c'est une réalisation de qualité ou une m****comme d'habitude. Prenez les devants et soyez méticuleux en corrigeant par vous même tout ce qui est évident (des titres mal alignés, des fontes hétérogènes, ...). Bref ouvrez les yeux, simplement...

Comment aborder la recette ?

La question qui se pose souvent est de savoir qui doit faire cette recette, et à quel moment.

Il n'y a pas de réponse universelle à la question car chaque projet est particulier. La réponse sera différente (elle doit être différente) selon la nature du projet, sa taille, sa complexité et les enjeux pour l'entreprise.

On n'abordera pas la phase de recette de la même façon pour un projet informatique touchant le système d'information d'une grande banque, que pour une petite application intranet. Dans le premier cas, on devine la complexité et le nombre de cas métier à vérifier pour éviter toute catastrophe aux répercutions économiques directes (on utilise d'ailleurs souvent des automates pour automatiser les tests). Dans le second cas, les fonctionnalités et les (vrais) enjeux d'entreprise restent limités. On ne sort pas l'artillerie lourde pour écraser une mouche.

La réponse sera différente aussi si vous faites appel à de la prestation. Entre le client (qui a spécifié l'application à réaliser) et la société de prestation (qui a développé l'outil) va s'instaurer une sorte de de relation de défiance : le client voulant rechercher tous les défauts pour avoir un produit parfait (quitte à glisser mine de rien des fonctionnalités non spécifiées) et la société de prestation voulant limiter les demandes de correction quitte à faire passer des bugs pour des fonctionnalité d'avant garde.

Les facteurs contractuels complexifient l'affaire en mêlant au projet informatique des considérations légales dont d'autres que moi parlent beaucoup mieux (voir le site http://laloidesparties.fr/ dont je fais la présentation dans ma rubrique Juridique IT).

La réponse sera aussi différente selon la technologie utilisée pour réaliser le projet. Si vous faites un projet en vous reposant sur un socle Sharepoint, vous n'allez pas tester toutes les fonctionnalités liées au natif de Sharepoint : vous vous contenterez des éléments développés spécifiquement, s'il y a en a. Encore faut il que la personne en charge de la recette comprenne Sharepoint et fasse la limite entre spécifique et natif et en comprenne la philosophie.

Le danger dans les directions informatiques c'est de définir un canevas de recette universel et d'y contraindre tous les types de projet, sous prétexte de normes, quelles que soient leurs natures, leur mode de réalisation, leur taille.

Il faut en effet garder une vision critique sur chaque projet et savoir reconnaître le bon mode pour réaliser la recette de telle ou telle application, et adapter les règles.

Qui va faire la recette ?

Reste à savoir qui doit faire la recette. Bien souvent des équipes sont dédiées aux recettes. Pour des projets industriels cela s'explique : les cas métier sont nombreux et une seule personne est incapable de dérouler les centaines, voir les milliers de cas possibles. Il faut industrialiser, paramétrer les tests et injecter des données anonymisées dans des automates : dans ces conditions la recette c'est un vrai métier.

Par contre pour des projets (beaucoup) moins complexes et avec des enjeux (beaucoup) moins importants, faut-il confier la recette à des personnes extérieures au projet ?

Pour ma part, depuis 15 ans je réalise des projets intranet ambitieux, de la conception / réalisation du portail intranet d'une entreprise, à des outils métier utilisés par plus de 3000 utilisateurs, en passant par la digitalisation entière de la bureautique d'une grande entreprise de 9000 personnes (avec fermeture de la hot line).

Quelle que soit la taille du projet, j'en ai toujours réalisé personnellement la recette. Plusieurs raisons à cela... C'est moi qui suis le porteur du projet face au client : je n'ai jamais délégué le soin à un autre de juger de la qualité de ce que je devais présenter à mon client direct. Mais plus concrètement je suis souvent le concepteur et donc je suis simplement le mieux placé pour juger de la conformité.

Pourtant, les chefs de projet préfèrent souvent déléguer cette tâche jugée ingrate à d'autres personnes, qui n'ont souvent aucune connaissance précise du projet. Cela comporte des risques sur la qualité du jugement sur le produit final, sur la lourdeur du traitement des retours (car le chef de projet, a un moment ou à un autre doit tout de même valider les décisions de correction).

Si je prends un exemple concret, imaginez que vous venez de faire construire VOTRE maison. Vous avez validé les plans, vous avez choisi la décoration, sur le papier en tout cas. Vous seul savez ce que vous attendez, et vous êtes le mieux placé pour savoir ce que votre constructeur vous a promis. Le jour de la remise des clés, accepteriez vous qu'un inconnu que vous ne connaissez ni d'eve ni d'Adam vienne à votre place décider que ce qui est livré vous convient !? Bien sur que non, parce que personne d'autre que vous n'a votre connaissance de vos attentes et personne d'autre que vous n'est autant impliqué.

Quand fait on la recette ?

Il y a plusieurs écoles sur le sujet. Les plus classiques d'entre vous vont prévoir plusieurs semaines de recette en toute fin de développement. C'est le grand moment de la surprise quand on découvre ce qui a été développé à partir d'un cahier des charges déjà à la base incompréhensible par le commun des mortels. Un grand moment de plaisir garanti ; et je suis toujours étonné qu'on espère quand même quelque chose qui corresponde aux attentes.

J'ai une autre approche : celle d'être constamment à côté des développeurs et de faire ma recette quasiment tous les jours. Je discute, je regarde, j'encourage, je constate, je m'étonne et je fais rectifier en temps réel si ce que je vois déjà à ce stade est à côté de la plaque. Qu'on soit en cycle en V ou en mode agile, c'est l'unique solution pour éviter les catastrophes au pied du mur quand c'est trop tard.

Reprenons l'image de la construction de la maison. Si vous venez chaque jour voir vos maçons, vous vous apercevrez vite que les fondations ne sont pas orientées dans la bonne direction. La correction prendra certes un jour ou deux, mais imaginez si vous ne vous en apercevez qu'une fois le toit monté.

Sans même parler de méthode agile (scrum et autres - qui ont leurs contraintes), cette façon de procéder me semble juste complément évidente. Pourtant, au sein de votre entreprise les esprits chagrins vous diront que "c'est pas possible" et vous donneront mille raison ;

- le développeur est loin (mais ça n'empêche pas de partager un écran à distance) - la réalisation est en forfait (ca ne m'empêchait pas de faire des visites régulières chez mon fournisseur, ce qui sécurisait les développeurs qui se savaient bien guidés - ils sont même demandeurs souvent - sauf si vous glissez en douce des évolutions non chiffrées) - c'est pas dans le process (traduction ; j'ai pas envie de réfléchir et de changer quoi que ce soit à ma petite vie bien réglée, même si mon process ne marche pas)

Faire la recette sur quel environnement ?

Ce qu'on appelle "les environnements" ce sont les espaces serveurs (pour résumer) qui hébergent votre nouvelle application.

On peut en dénombrer plusieurs : développement, intégration, pré-production, production. Passer l'application d'un environnement a l'autre coûte du temps et de l'énergie. Donc plus vous avez des environnements à "passer" plus votre projet sera long et coûteux.

Encore une fois certains projets industriels ont besoin de ce luxe en environnement pour valider toutes les étapes et "rejouer" en réel les opérations de mise en production. Hélas bien souvent le processus qui est justifié pour le système informatique d'un opérateur de téléphonie est appliqué à tous les projets de l'entreprise, grands et petits.

Voici comment le budget de votre petit projet intranet prend quelques zéros supplémentaires, pour gérer les passages d'environnement en environnement pour réduire des risques métiers qui n'existent pas forcément, mais en ajoutant par contre des risques planning et budgétaires eux bien réels.

D'autant que ces passages d'environnement en environnement ne sont pas des opérations simples. Souvent ceux qui ont la main sur ces environnement ne sont pas les acteurs projets. Autrement dit, ceux qui installent les applications n'ont aucune vraie connaissance de ce qu'ils installent sur le plan fonctionnel (ni même parfois techniques). Ils suivent les yeux fermés des documents que les vrais acteurs projets auront rédigés pendant des jours, voir des semaines alors qu'ils pourraient faire eux même l'opération en quelques heures. D'autant que les acteurs de la production n'ont pas toujours (pression financière sur l'infogérant oblige) ni grande expérience ni grande compétence dans les technologies en question.

Si on compare ca au métier de la chirurgie, on pourrait imaginer que le chirurgien n'aurait pas le droit de toucher au patient : il rédigerait un long document de mode opératoire, qu'il donnerait à une autre autre personne, un garçon boucher beaucoup moins expert mais moins cher aussi, qui ferait l'opération à sa place, en suivant mot à mot les explications du chirurgien, rédigées sur le document. J'exagère bien sûr... Quoique..

Avec des outils comme SharePoint, ça peut être encore plus compliqué : certains paramétrages du site ne pouvant pas se reporter d'environnement en environnement par du code ; il faut alors refaire les paramétrages "à la main" avec toutes les approximations que l'on imagine.

Bien souvent, la recette se concentre sur la préproduction. C'est ce qu'on me demandait à mon début de carrière, début des années 2000. Je devais prouver via un tas de documents qui me prenaient plus de temps à écrire que les propres spécifications du projet, que j'avais fait l'intégralité de la recette en pré production. Ensuite, l'opération se faisait en production, mais là, il ne m'était demandé aucun contrôle particulier. Grave erreur.

Car une fois en production, il faut refaire un ultime contrôle, avant re réouvrir le service aux utilisateurs, pour bien contrôler que tout fonctionne correctement. Car entre les deux environnements, tout n'est pas toujours d'équerre. Une recette qui s'est correctement déroulée en pré-production ne garantit en rien qu'il n'y ait aucun souci en production !

Pas de doute, la recette, c'est un vrai métier !