dossier :Gouvernance des systmes dinformation
Recette dune application :
priode de grand danger
1. Prparer la recette
1.2. Le protocole de recette
Une recette nest pas une aventure
improvise. Il convient tout dabord
de sentendre sur ce quil convient
de faire et de bien prciser les responsabilits. Cinq points sont essentiels :
Document bien trop souvent absent
des projets.Le but de ce document est
de fixer les conditions de ralisation de
la recette et surtout de sa validation. Il
traite non seulement de la recette
fonctionnelle vrification que le
comportement de lapplication est
bien celui attendu au vu des spcifications mais aussi de la recette technique celle qui valide le fonctionnement de lapplication dun point de
vue informatique. Parmi les points cls
qui doivent figurer dans ce document
se trouvent :
la mise en uvre dun environnement de test,
le protocole de recette,
Catherine Leloup,
Ingnieur Conseil
le cahier de recette,
les jeux dessais,
les responsabilits de recette.
La recette dune application
ou dun module applicatif est
la dfinition des anomalies : ce
1.1. Lenvironnement de test
souvent une priode difficile
dun projet. Pourtant, cest
une priode cl, dont linsuccs peut sensiblement obrer
le fonctionnement en service
de lapplication et se rvler
par la suite un gouffre financier en matire de maintenance. Une dmarche souvent trop floue et un manque
de prparation sont souvent
La revue n 83 - Juin 2006
lorigine de priodes de
12
recette qui sternisent, sans
quune relle visibilit des
modules accepts et des
corrections restant faire
soit suffisante.
Par dfinition, durant la recette, tout
peu arriver,y compris la destruction de
donnes, la saisie dinformations incohrentes,les plantages de machine,
etc. La moindre des choses est donc
de disposer dun environnement de
recette (machines et logiciels) qui
puisse tre momentanment hors service, sans que la vie quotidienne des
utilisateurs nen soit perturbe. Une
mauvaise pratique pourtant bien
rpandue consiste sous-dimensionner les serveurs de recette faute de
ressources techniques disponibles le
plus souvent ou bien considrer
comme environnement de test la
future machine de production, ce qui
rend videmment ensuite la mise en
production problmatique. Surtout
quand la ralisation est dcoupe en
lots, livrs au fur et mesure.
En outre, disposer dune plate-forme
de test performante, cest aussi bnficier dun environnement de formation et donc tre relativement serein
par rapport aux erreurs initiales que
ne manqueront pas de faire les utilisateurs.
quest une anomalie bloquante,
grave, mineure,
les modes opratoires relatifs la
dclaration des anomalies, leurs corrections et leur suivi,
le calendrier de ralisation de la
recette, sans oublier la prise en
compte les dlais requis pour la ralisation des corrections, et les nouveaux tests de validation,
les conditions souvent exprimes
en nombre danomalies de chaque
type tolr de prononciation de la
recette,
le traitement des cas particuliers,
comme les anomalies non reproductibles.
Sans ce document, cest la porte
ouverte aux interprtations de la gravit des anomalies, source prouve
de tensions dans les projets et de leurs
consquences classiques, entre dcouragement et dsespoir.
1.3. Le cahier de recette
Le cahier de recette est le document
qui dcrit le comportement que doit
avoir le systme tester, pour tre
conforme aux spcifications valides
Gouvernance des systmes dinformation dossier
pralablement. Trop souvent, ce document est crit au moment de la recette
cest--dire quand les dveloppements logiciels sont termins ou presque ; en
ralit, sa rdaction devrait tre lance ds la validation des spcifications. videmment, il doit tre valid par toutes les parties prenantes.
Lui aussi comprend deux volets : recette fonctionnelle qui sera ralise par les
quipes de la matrise douvrage et recette technique qui relvera des quipes
informatiques.
1.4. Les jeux dessais
Les jeux dessais, au pluriel. En effet, une recette nest pas une opration autonome et indpendante de la vie de lapplication. Il est aussi de bonne pratique de
vrifier dabord le fonctionnement en rgime de croisire de lapplication,puis
de la secouer un peu pour sassurer que les cas la marge ne gnrent pas de
problmes majeurs.Cela vaut aussi bien pour la recette fonctionnelle,o lon sattachera tester lapplication sur des donnes un peu exceptionnelles,que pour la
recette technique ou lon simulera par exemple, une monte en charge rapide.
1.5. Les responsabilits
La recette est une tape qui demande une relle concertation entre les intervenants du projet (matrise douvrage, matrise duvre, mais aussi entits bnficiaires de lapplication).Les recommandations que lon peut faire cet gard sont
une rpartition des rles comme suit :
lapplication doit tre soigneusement
encadre,afin notamment de garantir
sa disponibilit. Le droulement du
cahier de recette nest, il faut bien le
constater, quune premire tape. En
effet, par principe, des anomalies
vont tre dtectes.Et donc perturber
la recette : autrement dit, une erreur
constate va potentiellement induire
dautres dysfonctionnements, dont
la teneur ne peut tre raisonnablement comprises que par lensemble
de lquipe projet. Ainsi, le contrle
dune zone de donnes comme
une date qui ne fonctionne pas
correctement, cest la porte ouverte
nimporte quoi au niveau du fonctionnement de lapplication en
termes de relances, workflow et
autres gestions sappuyant sur un
calendrier. Do anomalies en cascade, aux effets divers, mais aux
mmes causes.
Fig. 1 : Les responsabilits en matire de recette
Bnficiaires
Matrise
duvre
Dfinir lenvironnement de recette
Valide
Valide
Dfinit
Rdiger le protocole de recette
Valide
Valide
Rdige
Rdiger le cahier de recette fonctionnelle
Rdige
Valide
Valide
Rdiger le cahier de recette technique
Valide
Valide
Rdige
tablir les jeux dessais
Valide
Rdige
Valide
Enfin, il est essentiel que toutes les ressources notamment humaines soient
mobilises en temps et heure.
2. Raliser la recette
Tout est prt pour effectuer la recette. Toutefois, quelques prcautions
complmentaires sont ncessaires, que nous rsumerons en quatre points :
sassurer que tous les protagonistes ont bien compris les rgles du jeu et
sont prts les appliquer,
vrifier que les attendus de la nouvelle application sont bien compris,
organiser la recette pour fournir tout moment une visibilit relle sur
lavancement,
conclure.
2.1. Les rgles du jeu
et leur application
Les rgles du jeu sont justement dcrites dans le protocole de recette et le
cahier de recette. Quoiquil en soit, cela ne suffit pas. Lquipe qui va tester
En dautres termes, un cahier de
recette tant fonctionnel que technique doit tre conu en modules
afin de vrifier avant tout la solidit
de lapplication et de son utilisation.
La dmarche doit aussi prvoir des
arrts pour permettre de raliser
les corrections des anomalies bloquantes ou graves. Cest souvent
une vue de lesprit de croire quil suffit de passer tout le cahier de recette
pour conclure. En outre, les petits
problmes techniques ont souvent
des effets dramatiques sur les utilisateurs et la srnit est une valeur
essentielle de tout bon testeur.
Enfin, la disponibilit des utilisateurs
qui vont raliser la recette fonctionnelle ne suffit pas : la ractivit de
lquipe de matrise duvre et sa
capacit fournir un support
lquipe de recette sont indispensables : si lquipe qui effectue la
recette a au pralable reu une
formation, elle nest pas pour autant
encore un utilisateur chevronn
de lapplication.
La revue n 83 - Juin 2006
Matrise
douvrage
Tches
13
dossier :Gouvernance des systmes dinformation
2.2. Les attendus
de la nouvelle application
Qui dit nouvelle application dit dans
95 % des cas changement des processus mtiers quelle supporte.
Pour la recette fonctionnelle, il est
indispensable que les quipes de
recette soient au fait de ces volutions et testent bien ce que lapplication est suppose faire et surtout
pas leur mode de fonctionnement
actuel ou pass. Cest aux directions
matrise douvrage et aux directions
bnficiaires davoir au pralable largement inform et form les
quipes qui effectuent la recette
fonctionnelle afin que celle-ci se
concentre sur le fonctionnement de
loutil et non pas sur les nouvelles
procdures et les modes opratoires. Il est en effet une constante
dans la mise en uvre des technologies innovantes : le dlai dadaptation des utilisateurs est sans aucun
doute bien largement suprieur
celui ncessaire la matrise dun
outil informatique. Ngliger cet
aspect des choses, cest sexposer
des drives o lutilisateur va tester
ce quil croit obtenir alors quil doit
respecter strictement ce qui a t
convenu dans le cahier de recette.
En revanche, lutilisation de multiples jeux dessais nest pas interdite, au contraire.
La revue n 83 - Juin 2006
2.3. Organiser la recette
14
Une bonne pratique quon ne rappellera jamais assez est de ne pas
confondre recette fonctionnelle par
les utilisateurs et dbogage. Pour
cela, la mthode prouve est celle
de la recette usine : autrement
dit, la matrise duvre passe le
cahier de recette avec le premier jeu
dessais et ne livre lapplication en
recette aux utilisateurs, quune fois
quelle na elle-mme constat
aucune anomalie bloquante. Do
lintrt du protocole et du cahier de
recette. La littrature fourmille des
diffrences entre tests raliss par
les dveloppeurs et tests fonctionnels : cest la quadrature du cercle,
dans la mesure o aucun dvelop-
peur ne peut anticiper les usages de
lapplication et aucun utilisateur
approfondir la construction technique de lapplication.
recette initiale suivie dune priode
probatoire ultrieure (1) de lapplication en fonctionnement sont galement prconiser.
Une autre bonne pratique est le
rfrencement des anomalies bloquantes comme mineures systmatiquement et dans un systme
adapt, qui nest pas la messagerie
lectronique. Plus le format des
dclarations danomalies sera prcis,
plus les diagnostics et corrections
seront aises. Sans oublier de bien
mettre en vidence les anomalies
fonctionnelles qui ont les mmes
causes techniques et de planifier les
corrections soigneusement.
En effet, lanalyse des retards lis aux
projets sont bien souvent sur les
phases amont et aval de celle du
dveloppement logiciel ; la recette
ne fait pas exception, et les calendriers ne prvoyant que quelques
jours de recette sont compltement
irralistes.
Une troisime bonne pratique, cest
de procder au niveau de la fourniture des corrections par la matrise
duvre par livraisons successives
en environnement de recette et de
ne surtout pas considrer la plateforme de test comme une plateforme annexe de dveloppement
logiciel. Chaque livraison devra tre
accompagne de la liste des anomalies corriges et re-testes.
Enfin, sil arrive que certaines anomalies ne soient pas reproductibles,
il ne faut surtout pas les ignorer pour
autant, mais bien au contraire,
accrotre le volume de tests, en faisant voluer les environnements
(poste de travail, paramtrage 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, matrialise par un procs-verbal qui
consigne que lapplication 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 deuxime
recette aprs correction de toutes
les anomalies. La dmarche de
3. Conclusion
Parent souvent pauvre du cycle de
dveloppement logiciel, la recette
est pourtant une tape charnire.
Les projets ambitieux sont souvent
lotis en plusieurs tapes, et la recette
de chaque lot est videmment
lourde, car il ne suffit pas de vrifier
chaque lot indpendamment, mais
aussi de sassurer des tests de non
rgression (techniques et fonctionnels).
Une des difficults frquentes dans
ce processus est li la difficult de
rdaction des cahiers de recette et la
mise au point des jeux dessais. Car,
au-del de la connaissance mtiers
qui est bien sr indispensable, il faut
aussi que les responsables utilisateurs aient le got de se mettre
en situation, sans pour autant
oublier de respecter les attendus du
systme. Mais il faut aussi que la matrise duvre comprenne lutilisation 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. Vrification daptitude et Vrification de
Service Rgulier.
