Dans le monde culinaire, ce que l’on appelle recette, c’est la liste des instructions que l’on va suivre en réalisant un plat ou un dessert par exemple. Dans le monde informatique et pour schématiser : la recette se passe après, une fois qu’on a réalisé le plat en suivant les instructions (c’est à dire une fois que l’application a été développée en suivant les spécifications ou le cahier des charges).
On va vérifier que celle-ci est conforme, que les instructions initiales ont bien été suivies et pour reprendre l’analogie, que les ingrédients une fois mélangés ne présentent pas de toxicité, de goût désagréable ou ne déclenchent pas des allergies non désirées.
On va donc au cours de la recette mesurer les éventuels écarts entre ce qui était attendu et ce qui a était livré. On va peut être découvrir des dysfonctionnements non détectés lors des tests, qui arrivent dans certains cas de figure non anticipés au stade théorique.
La recette selon les projets va être plus ou moins formalisée.
Tous les projets ne nécessitent pas un cahier de recette et un découpage précis des tests unitaires en une multitude de micro fonctions.
Un accès à une solution de gestion de tickets (nous utilisons pour notre part l’outil Redmine) permet de remonter les incidents et de suivre leur prise en charge jusqu’à leur résolution. Ce processus est maintenu lors des phases de garantie et de maintenance corrective.
Il est possible selon la dimension du projet et son découpage en parties ou étapes distinctes d’avoir plusieurs recettes intermédiaires où l’on va vérifier le bon fonctionnement et la conformité de plusieurs sous-ensembles au fur et à mesure de leur réalisation et de leur livraison. Dans ce cas, une recette finale a lieu pour vérifier le fonctionnement global une fois tous les sous-ensembles réalisés et livrés.
Quand la recette est réalisée et validée côté client, la garantie peut commencer. Pour un maximum d’efficacité, la recette doit être réalisée dans un délai raisonnable après livraison de manière à ce que les équipes de développement soient encore « dans le jus » du projet et donc en mesure d’intervenir rapidement (sans une période de réappropriation qui est nécessaire quand un délai trop important s’écoule ou quand les développeurs travaillent dans l’intervalle sur un nouveau projet qui n’a rien à voir).
Le développement n’étant pas une science exacte, il est possible qu’apparaissent au fil de l’eau des petits dysfonctionnements dans certains cas précis de la vie réelle sur des modes de fonctionnement spécifique au métier de nos clients qui n’auraient pas été documentés au moment de la conception.
C’est le cycle normal de développement des logiciels et des applications, des situations nouvelles peuvent apparaitre en cours de tests, de recette ou de production.
Les phases de garantie initiale, puis de maintenance corrective une fois celle-ci échue, permettent de prendre en charge les dysfonctionnements / bugs qui pourraient apparaitre après la phase de recette.
