Recette d`une application

dossier :Gouvernance des systèmes d’information
Recette d’une application :
période de grand danger
1. Préparer la recette
1.2. Le protocole de recette
Une recette n’est pas une aventure
improvisée. Il convient tout d’abord
de s’entendre sur ce qu’il convient
de faire et de bien préciser les responsabilités. Cinq points sont essentiels :
Document bien trop souvent absent
des projets.Le but de ce document est
de fixer les conditions de réalisation de
la recette et surtout de sa validation. Il
traite non seulement de la recette
fonctionnelle – vérification que le
comportement de l’application est
bien celui attendu au vu des spécifications – mais aussi de la recette technique – celle qui valide le fonctionnement de l’application d’un point de
vue informatique. Parmi les points clés
qui doivent figurer dans ce document
se trouvent :
• la mise en œuvre d’un environnement de test,
• le protocole de recette,
Catherine Leloup,
Ingénieur Conseil
• le cahier de recette,
• les jeux d’essais,
• les responsabilités de recette.
La recette d’une application
ou d’un module applicatif est
• la définition des anomalies : ce
1.1. L’environnement de test
souvent une période difficile
d’un projet. Pourtant, c’est
une période clé, dont l’insuccès peut sensiblement obérer
le fonctionnement en service
de l’application et se révéler
par la suite un gouffre financier en matière de maintenance. Une démarche souvent trop floue et un manque
de préparation sont souvent
• La revue n° 83 - Juin 2006
à l’origine de périodes de
12
recette qui s’éternisent, sans
qu’une réelle visibilité des
modules acceptés et des
corrections restant à faire
soit suffisante.
Par définition, durant la recette, tout
peu arriver,y compris la destruction de
données, la saisie d’informations incohérentes,les « plantages » de machine,
etc. La moindre des choses est donc
de disposer d’un environnement de
recette (machines et logiciels) qui
puisse être momentanément hors service, sans que la vie quotidienne des
utilisateurs n’en soit perturbée. Une
mauvaise pratique pourtant bien
répandue consiste à sous-dimensionner les serveurs de recette – faute de
ressources techniques disponibles le
plus souvent – ou bien à considérer
comme environnement de test la
future machine de production, ce qui
rend évidemment ensuite la mise en
production problématique. Surtout
quand la réalisation est découpée en
lots, livrés au fur et à mesure.
En outre, disposer d’une plate-forme
de test performante, c’est aussi bénéficier d’un environnement de formation et donc être relativement serein
par rapport aux erreurs initiales que
ne manqueront pas de faire les utilisateurs.
qu’est une anomalie bloquante,
grave, mineure,
• les modes opératoires relatifs à la
déclaration des anomalies, leurs corrections et leur suivi,
• le calendrier de réalisation de la
recette, sans oublier la prise en
compte les délais requis pour la réalisation des corrections, et les nouveaux tests de validation,
• les conditions – souvent exprimées
en nombre d’anomalies de chaque
type toléré – de prononciation de la
recette,
• le traitement des cas particuliers,
comme les anomalies non reproductibles.
Sans ce document, c’est la porte
ouverte aux interprétations de la gravité des anomalies, source éprouvée
de tensions dans les projets et de leurs
conséquences classiques, entre découragement et désespoir.
1.3. Le cahier de recette
Le cahier de recette est le document
qui décrit le comportement que doit
avoir le système à tester, pour être
conforme aux spécifications validées
Gouvernance des systèmes d’information dossier
préalablement. Trop souvent, ce document est écrit au moment de la recette
– c’est-à-dire quand les développements logiciels sont terminés ou presque ; en
réalité, sa rédaction devrait être lancée dès la validation des spécifications. Évidemment, il doit être validé par toutes les parties prenantes.
Lui aussi comprend deux volets : recette fonctionnelle qui sera réalisée par les
équipes de la maîtrise d’ouvrage et recette technique qui relèvera des équipes
informatiques.
1.4. Les jeux d’essais
Les jeux d’essais, au pluriel. En effet, une recette n’est pas une opération autonome et indépendante de la vie de l’application. Il est aussi de bonne pratique de
vérifier d’abord le fonctionnement « en régime de croisière » de l’application,puis
de la « secouer » un peu pour s’assurer que les cas à la marge ne génèrent pas de
problèmes majeurs.Cela vaut aussi bien pour la recette fonctionnelle,où l’on s’attachera à tester l’application sur des données un peu exceptionnelles,que pour la
recette technique ou l’on simulera par exemple, une montée en charge rapide.
1.5. Les responsabilités
La recette est une étape qui demande une réelle concertation entre les intervenants du projet (maîtrise d’ouvrage, maîtrise d’œuvre, mais aussi entités bénéficiaires de l’application).Les recommandations que l’on peut faire à cet égard sont
une répartition des rôles comme suit :
l’application doit être soigneusement
encadrée,afin notamment de garantir
sa disponibilité. Le déroulement du
cahier de recette n’est, il faut bien le
constater, qu’une première étape. En
effet, par principe, des anomalies
vont être détectées.Et donc perturber
la recette : autrement dit, une erreur
constatée va potentiellement induire
d’autres dysfonctionnements, dont
la teneur ne peut être raisonnablement comprises que par l’ensemble
de l’équipe projet. Ainsi, le contrôle
d’une zone de données – comme
une date – qui ne fonctionne pas
correctement, c’est la porte ouverte
à n’importe quoi au niveau du fonctionnement de l’application en
termes de relances, workflow et
autres gestions s’appuyant sur un
calendrier. D’où anomalies en cascade, aux effets divers, mais aux
mêmes causes.
Fig. 1 : Les responsabilités en matière de recette
Bénéficiaires
Maîtrise
d’œuvre
Définir l’environnement de recette
Valide
Valide
Définit
Rédiger le protocole de recette
Valide
Valide
Rédige
Rédiger le cahier de recette fonctionnelle
Rédige
Valide
Valide
Rédiger le cahier de recette technique
Valide
Valide
Rédige
Établir les jeux d’essais
Valide
Rédige
Valide
Enfin, il est essentiel que toutes les ressources – notamment humaines – soient
mobilisées en temps et heure.
2. Réaliser la recette
Tout est prêt pour effectuer la recette. Toutefois, quelques précautions
complémentaires sont nécessaires, que nous résumerons en quatre points :
• s’assurer que tous les protagonistes ont bien compris les règles du jeu et
sont prêts à les appliquer,
• vérifier que les attendus de la nouvelle application sont bien compris,
• organiser la recette pour fournir à tout moment une visibilité réelle sur
l’avancement,
• conclure.
2.1. Les règles du jeu
et leur application
Les règles du jeu sont justement décrites dans le protocole de recette et le
cahier de recette. Quoiqu’il en soit, cela ne suffit pas. L’équipe qui va tester
En d’autres termes, un cahier de
recette – tant fonctionnel que technique – doit être conçu en modules
afin de vérifier avant tout la solidité
de l’application et de son utilisation.
La démarche doit aussi prévoir des
« arrêts » pour permettre de réaliser
les corrections des anomalies bloquantes ou graves. C’est souvent
une vue de l’esprit de croire qu’il suffit de passer tout le cahier de recette
pour conclure. En outre, les petits
problèmes techniques ont souvent
des effets dramatiques sur les utilisateurs et la sérénité est une valeur
essentielle de tout bon testeur.
Enfin, la disponibilité des utilisateurs
qui vont réaliser la recette fonctionnelle ne suffit pas : la réactivité de
l’équipe de maîtrise d’œuvre et sa
capacité à fournir un support à
l’équipe de recette sont indispensables : si l’équipe qui effectue la
recette a au préalable reçu une
formation, elle n’est pas pour autant
– encore – un utilisateur chevronné
de l’application.
• La revue n° 83 - Juin 2006
Maîtrise
d’ouvrage
Tâches
13
dossier :Gouvernance des systèmes d’information
2.2. Les attendus
de la nouvelle application
Qui dit nouvelle application dit dans
95 % des cas changement des processus métiers qu’elle supporte.
Pour la recette fonctionnelle, il est
indispensable que les équipes de
recette soient au fait de ces évolutions et testent bien ce que l’application est supposée faire et surtout
pas leur mode de fonctionnement
actuel ou passé. C’est aux directions
maîtrise d’ouvrage et aux directions
bénéficiaires d’avoir au préalable largement informé et formé les
équipes qui effectuent la recette
fonctionnelle afin que celle-ci se
concentre sur le fonctionnement de
l’outil et non pas sur les nouvelles
procédures et les modes opératoires. Il est en effet une constante
dans la mise en œuvre des technologies innovantes : le délai d’adaptation des utilisateurs est sans aucun
doute bien largement supérieur à
celui nécessaire à la maîtrise d’un
outil informatique. Négliger cet
aspect des choses, c’est s’exposer à
des dérives où l’utilisateur va tester
ce qu’il croit obtenir alors qu’il doit
respecter strictement ce qui a été
convenu dans le cahier de recette.
En revanche, l’utilisation de multiples jeux d’essais n’est pas interdite, au contraire.
• La revue n° 83 - Juin 2006
2.3. Organiser la recette
14
Une bonne pratique qu’on ne rappellera jamais assez est de ne pas
confondre recette fonctionnelle par
les utilisateurs et débogage. Pour
cela, la méthode éprouvée est celle
de la recette « usine » : autrement
dit, la maîtrise d’œuvre passe le
cahier de recette avec le premier jeu
d’essais et ne livre l’application en
recette aux utilisateurs, qu’une fois
qu’elle n’a elle-même constaté
aucune anomalie bloquante. D’où
l’intérêt du protocole et du cahier de
recette. La littérature fourmille des
différences entre tests réalisés par
les développeurs et tests fonctionnels : c’est la quadrature du cercle,
dans la mesure où aucun dévelop-
peur ne peut anticiper les usages de
l’application et aucun utilisateur
approfondir la construction technique de l’application.
recette initiale suivie d’une période
probatoire ultérieure (1) de l’application en fonctionnement sont également à préconiser.
Une autre bonne pratique est le
référencement des anomalies – bloquantes comme mineures – systématiquement et dans un système
adapté, qui n’est pas la messagerie
électronique. Plus le format des
déclarations d’anomalies sera précis,
plus les diagnostics et corrections
seront aisées. Sans oublier de bien
mettre en évidence les anomalies
fonctionnelles qui ont les mêmes
causes techniques et de planifier les
corrections soigneusement.
En effet, l’analyse des retards liés aux
projets sont bien souvent sur les
phases amont et aval de celle du
développement logiciel ; la recette
ne fait pas exception, et les calendriers ne prévoyant que quelques
jours de recette sont complètement
irréalistes.
Une troisième bonne pratique, c’est
de procéder au niveau de la fourniture des corrections par la maîtrise
d’œuvre par livraisons successives
en environnement de recette et de
ne surtout pas considérer la plateforme de test comme une plateforme annexe de développement
logiciel. Chaque livraison devra être
accompagnée de la liste des anomalies corrigées et re-testées.
Enfin, s’il arrive que certaines anomalies ne soient pas reproductibles,
il ne faut surtout pas les ignorer pour
autant, mais bien au contraire,
accroître le volume de tests, en faisant évoluer les environnements
(poste de travail, paramétrage des
logiciels clients, comptes utilisateurs,
etc.). Et surtout garder trace de leur
existence.
2.4. Conclure
Comme toutes les bonnes choses,
les recettes ont une fin, matérialisée par un procès-verbal qui
consigne que l’application est utilisable, moyennant éventuellement
quelques corrections mineures restant à faire, selon un calendrier
convenu de toutes les parties. Il est
rarissime que le respect du calendrier de mise en production soit
strictement compatible avec la correction – et donc une deuxième
recette après correction – de toutes
les anomalies. La démarche de
3. Conclusion
Parent souvent pauvre du cycle de
développement logiciel, la recette
est pourtant une étape charnière.
Les projets ambitieux sont souvent
lotis en plusieurs étapes, et la recette
de chaque lot est évidemment
lourde, car il ne suffit pas de vérifier
chaque lot indépendamment, mais
aussi de s’assurer des tests de non
régression (techniques et fonctionnels).
Une des difficultés fréquentes dans
ce processus est lié à la difficulté de
rédaction des cahiers de recette et la
mise au point des jeux d’essais. Car,
au-delà de la connaissance métiers
qui est bien sûr indispensable, il faut
aussi que les responsables utilisateurs aient le « goût » de se mettre
en situation, sans pour autant
oublier de respecter les attendus du
système. Mais il faut aussi que la maîtrise d’œuvre comprenne l’utilisation qui sera faite du logiciel. En
quelque sorte, un premier pas bien
utile pour pouvoir ensuite assurer
une bonne maintenance applicative,
et faciliter le dialogue…
1. Vérification d’aptitude et Vérification de
Service Régulier.