Validation

Lorsque le programme est réalisé, le maître d’œuvre doit s’assurer qu’il

répond bien au cahier des charges. Pour cela, il est nécessaire de réaliser
des tests. Ces derniers se feront sur des plates-formes dédiées (dévelop-
pement, validation, intégration ) selon les besoins, par des testeurs
(de préférence une équipe différente et impartiale) couvrant l’intégralité
des tests nécessaires à la validation technique du bon fonctionnement du
livrable et surtout de la concordance fonctionnelle du livrable avec les
exigences formulées dans le cahier des charges. Par conséquent, nous
pouvons scinder cette opération en deux phases : les tests techniques et
les tests fonctionnels.

Tests techniques
Au nombre de trois, ils sont réalisés très majoritairement par des déve-
loppeurs.
Le test unitaire permet de s’assurer du fonctionnement correct d’une
partie ou d’un module d’une application. Il s’agit pour le programmeur
de tester un module, indépendamment du reste du programme, afin de
s’assurer qu’il répond aux spécifications fonctionnelles, en toutes
circonstances.
Les tests d’intégration succèdent aux tests unitaires et consistent, après
validation de chaque développement, à vérifier le bon fonctionnement
de l’ensemble des modules développés unitairement dans leur futur
contexte technique d’utilisation, afin de livrer un produit fini.
 Gérer un projet de A à Z – Les étapes projet

Ensuite sont entrepris les tests de performance destinés à vérifier que la

montée en charge (nombre de connexions simultanées équivalant à la
population utilisatrice cible) n’engendre pas une dégradation des
performances ou une dégradation minime garantissant encore une
utilisation du livrable dans des conditions acceptables.

Tests fonctionnels
Par définition, ce type de test ne se concentre que sur les fonctionnalités
d’une application, sans se soucier des détails d’implémentation, contrai-
rement aux tests unitaires. C’est le test pratiqué par l’utilisateur final, qui
peut ainsi, et selon des scénarios prédéfinis, parcourir les menus de
l’application pour contrôler chacun d’entre eux. Il valide alors la présence
de chaque fonctionnalité attendue et la conformité de son comportement
face aux exigences. Les tests fonctionnels complètent les tests unitaires et
d’intégration : ce sont des boîtes noires qui vérifient les fonctionnalités du
système complet, conformément à chaque besoin énoncé.
En complément, le livrable peut être soumis à une multitude de profils
utilisateurs différents afin de vérifier les habilitations (droits d’accès aux
différents menus et options mis à disposition des futurs utilisateurs).
Cette dernière opération garantit la confidentialité des données et évite
donc, par exemple, que la fiche de paie du directeur général ne soit
accessible à l’ensemble du personnel.
Au-delà des habilitations, nous parlerons des tests de sécurité. Il est difficile
de les définir avec précision dans la mesure où ils sont spécifiques à chaque
programme. Toutefois les grandes lignes pourraient être les suivantes :
 facilité d’intrusion dans l’application ou une base de données ;
 décryptage ou lisibilité des mots de passe ;
 déverrouillage des conditions d’utilisation du programme (licence,
date limite d’utilisation, nombre de clients, fournisseurs ) ;
 saturation des performances du programme ;
 accessibilité aux lignes de programmation ;
 facilité de captage des flux d’informations échangés ;
 facilité de modification ou de suppression de données.

Cette liste non exhaustive sera à adapter en fonction de votre contexte.

 Manager un projet informatique

Plan de test
Pour faire effectuer les tests d’intégration auprès des utilisateurs, vous
pouvez utilisez un plan de test. Ce document recense, d’une part, les
objectifs et les moyens pour réaliser les tests et, d’autre part, l’organisa-
tion technique des tests.
L’utilisateur y trouvera le déroulement des tests dans le temps, ainsi que
des points de repère, en particulier les conditions qui ne justifient pas leur
poursuite. Faisant partie des documents contractuels du projet, le plan de
test pourra être considéré comme un des livrables du plan qualité.
La démarche de réalisation du plan de test se compose de quatre étapes :
 la préparation définit le périmètre dans lequel s’effectueront les tests
(plates-formes techniques et compétences associées) ;
 la conception concerne l’élaboration du plan de test en définissant
les différents scénarios et les jeux d’essais nécessaires ;
 l’exécution désigne le déroulement des scénarios ;
 le bilan consiste à rédiger les bilans associés.

En outre, six types d’informations composent le plan de test : identifi-

cation (libellé, date, nom du testeur, appréciation globale du test) ;
objectifs ; environnement ; liste des scénarios ; description de chaque
scénario ; observation après test.
Les tests ayant validé le bon fonctionnement de l’application, celle-ci sera
présentée à la maîtrise d’ouvrage pour confirmer l’adéquation avec le
cahier des charges. Cette phase de validation permet de s’affranchir
d’éventuels dysfonctionnements futurs de l’application.
À ce niveau, l’application est prête et vous pouvez donc envisager de
passer à la phase de recette.

Recette et réception
La recette, encore appelée essais de réception, est la vérification de la
conformité de l’ouvrage en regard de la demande formulée dans le
dossier initial. C’est un processus rigoureux et méthodologique effectué
dès la réception de l’ouvrage.
 Gérer un projet de A à Z – Les étapes projet

Comme nous l’avons vu précédemment, la mise en place d’une nouvelle

application se découpe en étapes successives au cours desquelles
différents travaux doivent être effectués et différents livrables sont
produits. Il s’agit de bien les réceptionner et c’est ainsi que se met en
place la phase de recette et réception.
Cette phase de réception peut être facilitée par la mise en place d’un
document type qui constituera la trame de votre recette. Il sera à produire
ou à mettre à jour par l’équipe projet lors de la phase de déve- loppement,
au cours de l’étape d’étude détaillée, en préparation de la recette interne.
Il doit pouvoir s’appliquer lors de chaque réception des versions
successives d’une application ou après mise à jour éventuelle.
Voici un exemple de contenu d’un document de réception.

Présentation générale
 Objectifs de la réception : il s’agit de décrire brièvement les objec-
tifs de la réception. Par exemple, le but de la réception est de faire
une recette logicielle afin de vérifier la conformité fonctionnelle des
logiciels par rapport aux spécifications du cahier des charges, leur
bonne intégration dans le système d’information existant, ainsi que la
non-régression fonctionnelle.
 Présentation des livrables à réceptionner : il s’agit de décrire les
éléments sur lesquels porte la réception. Par exemple, s’agit-il de
réceptionner les logiciels applicatifs, des outils ou utilitaires, ou encore
des modules externes ? Si le livrable est une documentation, de quel
type s’agit-il ? Étude technique, plan de test, support de formation ?
 Limites : ce paragraphe précise ce qui n’est pas couvert par la phase
de réception, comme les tests unitaires ou d’intégration, les tests de
performance ou de non-régression.
 Vocabulaire ou abréviations : il s’agit de définir les termes particu-
liers ou abréviations utilisés dans le document.

Responsabilité
Ce paragraphe permet de définir les responsabilités de chaque équipe
pour la préparation et l’exécution de la réception.
 Manager un projet informatique

Généralement, une équipe de réception est identifiée au sein de l’équipe

projet. Il est souhaitable que l’équipe de réception soit diffé- rente de
l’équipe de spécification. Cette équipe est coordonnée par un
responsable, qui est, si possible, différent du chef de projet, pour pouvoir
arbitrer de manière impartiale le cas échéant.
L’équipe de réalisation est responsable de la livraison ; elle peut être, selon
le cas, responsable de l’installation des fournitures livrées sur les plates-
formes de réception et de leur mise en configuration opérationnelle,
surtout si par la suite elle est chargée de la diffusion de l’application sur
site utilisateur. Pendant la réception, l’équipe de réalisation est disponible
pour toute information nécessaire à l’équipe de réception. Si besoin, on
peut prévoir la présence de l’équipe de réalisation pendant la recette logi-
cielle : le responsable de l’équipe de réalisation est là en permanence,
accompagné de la personne ayant développé la partie du logiciel en cours
de test de réception.

Procédure de réception
Ce paragraphe contient les informations relatives aux procédures de
réception : tout d’abord les modalités de mise à disposition des livrables
par l’équipe de réalisation, puis la vérification des fournitures livrées et la
conformité des contenus attendus ainsi que la cohérence fonction- nelle
et technique du contenu.
Un document formel, le procès-verbal de réception, atteste de la bonne
fin de la réception et permettra de déclencher la facturation de la presta-
tion dans le cas d’un fournisseur externe. Le procès-verbal de réception
définitive peut n’être signé qu’à l’issue de la réception externe (passage
sur sites pilotes) si des clauses contractuelles le prévoient ainsi.
Le procès-verbal de réception indique les conclusions de la réception. Il
est cosigné par le chef de projet et le responsable de la réalisation. Si la
réception est acceptée sans réserves, il y a signature d’un procès-verbal de
réception définitive. Sinon, il y a signature d’un procès-verbal de récep-
tion provisoire, avec accord sur une nouvelle date de livraison. En ce cas,
le procès-verbal de réception définitive ne sera signé qu’après levée des
réserves ou bien à nouveau déroulement complet de la réception.
 Gérer un projet de A à Z – Les étapes projet

Ajournement de la réception
Ce paragraphe indique que la réception peut être ajournée pour non-
conformités majeures, lorsque l’équipe de réception estime que la qualité
de la livraison est insuffisante pour que les tâches de réception puissent
se dérouler dans des conditions optimales. Dans ce cas, l’équipe de
réalisation dispose d’un délai pour améliorer la qualité de la fourniture et
la reproposer lors d’une réception ultérieure.
Cette situation, qui devrait rester exceptionnelle, témoigne d’une qualité
de service faible et fait généralement l’objet d’ajustements au niveau
contractuel entre le client et le fournisseur.

Organisation de la recette
Cette partie reprend toutes les informations nécessaires à la préparation
et à l’exécution des tests sur l’application.
Il faudra déterminer l’importance et la nature des tests de recette en
tenant compte de la criticité du logiciel développé, de la qualité de service
que les utilisateurs attendent du logiciel, mais également du coût, de la
facilité et de la rapidité de rediffusion en cas d’anomalies bloquantes.
Notez que l’objectif des tests de réception n’est pas de couvrir l’ensemble
des points du cahier des charges mais un sous-ensemble représentatif
choisi parmi les points les plus critiques (du point de vue fiabilité,
ergonomie, complexité ).
Recensez également les points critiques à vérifier absolument. En effet
chaque application a des fonctions critiques, prioritaires pour l’utilisa-
teur, qui devront être couvertes par cette recette (par exemple, la confi-
dentialité, les sauvegardes/restaurations ou encore les temps de réponse).
Au niveau de l’organisation, la recette peut être décomposée en plusieurs
étapes qui assurent la progressivité de la vérification effectuée. Chaque
étape correspond à un objectif de test particulier. Voici quel- ques
exemples d’objectifs de tests.
 Manager un projet informatique

 Installation : consiste à générer et à installer l’application, et à faire la

mise en service et une démonstration simple, à l’aide de la documen-
tation (manuel d’installation ).
 Interface homme/machine : contrôle la présence et la conformité des
écrans, menus, états, etc., au niveau statique (présentations, respect
des normes d’ergonomie) et au niveau dynamique (enchaînement des
écrans, acceptation des valeurs nominales, résistance aux entrées erro-
nées, résistance aux erreurs d’utilisation, arrêts et reprises du dialogue).
 Fonctionnalités : contrôle le déroulement et le résultat de chaque
fonction utilisateur puis les enchaînements possibles (procédures
utilisateur). Tous les points du cahier des charges ne feront pas l’objet
de tests de réception. Néanmoins, les tests s’attacheront à vérifier les
points les plus sensibles du cahier des charges.
 Reprise des données : contrôle la récupération effective des données
depuis des applications existantes (données correctes, complètes ).
 Interfaces avec d’autres applications : contrôle la présence et al
conformité des liens avec d’autres applications, au niveau statique
(formats des fichiers ) et au niveau dynamique (enchaînement des
flux d’information, acceptation des valeurs nominales, résistance
aux entrées erronées, arrêts et reprises du dialogue).
 Performances : contrôle, en environnement opérationnel ou simulé,
la tenue des performances de temps (réponse, reprise ), d’occupa-
tion mémoire (centrale, secondaire ), de précision des calculs
Les conditions peuvent être nominales, aux limites, à pleine charge
ou en surcharge.
 Sécurité : concerne les contrôles d’accès et la résistance aux viola-
tions d’accès, puis la conservation de l’intégrité des données (y
compris après un arrêt de l’application).
 Robustesse : contrôle la résistance aux défauts des supports mémoire et
des interfaces, aux erreurs internes (tests aux limites), puis aux
changements de modes (nominal, dégradé ).
 Aspect réseau : contrôle le fonctionnement correct de l’application en
cas de multi-utilisateurs dans des contextes nominaux ou dégradés
(réseau en panne).
 Gérer un projet de A à Z – Les étapes projet

 Exploitation : vérifie que toutes les procédures d’exploitation

(sauvegarde, restauration ) satisfont à leurs objectifs.
Les étapes peuvent être organisées dans un ordre différent en fonction
des spécificités du projet et des facilités de recette.
Il est également possible d’organiser la recette en fonction des différentes
parties de l’application logicielle à « recetter » : par exemple, chaque étape
correspond à un domaine ou à un module du logiciel, et la dernière étape
permet de vérifier la cohérence de l’ensemble. Cela permet de continuer
la recette même si une anomalie bloquante est identifiée dans une étape.
Dans certains cas, l’équipe de réception peut effectuer une revue de code
sur un échantillon de programmes identifié. Cette revue de code s’appuie
sur les connaissances techniques de celui qui la réalise et sur les normes
de développement applicables au projet.

Déroulement de la recette
Ce paragraphe détaille les dispositions suivies pendant l’exécution des
tests, en termes de recueil des anomalies, livraison, suivi de l’avancement.
Si une revue de code (relecture de quelques programmes) est prévue, il
est préférable qu’elle se déroule dès le début de la recette. La revue de
code permet de vérifier le respect des normes de développement ; elle
peut donner lieu à l’émission de nouvelles normes de développement à
transmettre à l’équipe de réalisation pour la prochaine version de
l’application.
Les tests sont exécutés conformément aux dossiers préparés. L’équipe de
réalisation peut être présente pendant le déroulement des tests, mais les
scénarios de tests sont exécutés par un membre de l’équipe de réception.
En cas d’anomalies, il convient de créer des fiches d’anomalies et de les
transmettre à l’équipe de réalisation. Après correction des anomalies,
l’équipe de réalisation livre la nouvelle version. Notez que la recette doit
être menée comme un mini-projet avec des tâches identifiées et affec-
tées à des ressources, une planification et un suivi de l’avancement.
Lorsque la recette est validée par l’ensemble des parties, la livraison peut
avoir lieu.
 Manager un projet informatique

Livraison

Mise à disposition
Il s’agit de fournir l’application aux utilisateurs finaux. Cette livraison
pourrait se faire en deux temps.
1. Sites pilotes
La mise en place de sites pilotes19 permet de tester l’ouvrage dans sa
dimension globale technique, comme dans celle de l’organisation et de
l’adhésion des utilisateurs. L’expérience des sites pilotes permet de
préparer le déploiement, de mieux en appréhender la charge, et d’en
identifier les bugs20, ou dysfonctionnements découverts, et de les
corriger.
2. Généralisation
Il s’agit du déploiement en masse du livrable auprès des utilisateurs
finaux. Un déploiement réussi sur les sites pilotes ne signifie pas systé-
matiquement que le déploiement généralisé réussira. En effet, lors de
l’expérimentation, les référents des sites pilotes auront une motivation
différente de celle des utilisateurs. De plus, chaque dysfonctionnement
sera mis sur le compte de l’expérimentation (périodes de tests grandeur
nature). La généralisation implique souvent des changements dans les
habitudes de travail. À ce titre, nous pourrions citer :
 nouveau produit ;
 inexpérience ;
 motivation.
On désigne ainsi par « conduite du changement » toutes les étapes
d’accompagnement permettant aux utilisateurs finaux d’acquérir de
nouvelles habitudes et de changer de culture pour l’utilisation du

19. Ils doivent concerner un nombre limité, mais significatif, d’utilisateurs. Les données sont
réelles, mais leur exploitation n’est pas forcément prise en compte immédiatement.
20. Anomalie de fonctionnement d’un programme informatique.
 Gérer un projet de A à Z – Les étapes projet

nouveau produit, mais aussi un suivi par la hotline 21. La conduite du

changement englobe notamment la formation à l’utilisation du produit
ainsi que l’accompagnement des utilisateurs.
En outre, lorsque le projet vise un nombre d’utilisateurs finaux très
important, il n’est souvent pas envisageable de passer directement d’une
expérimentation à une généralisation. Selon les fonctionnalités livrées, il
peut être nécessaire de faire des tests de montée en charge (on parle
parfois de montée en cadence), c’est-à-dire simuler un nombre d’utili-
sateurs de plus en plus grand afin d’estimer si le produit est potentielle-
ment capable de supporter la charge totale (utilisation simultanée par le
nombre d’utilisateurs prévu dans le cahier des charges). Il est également
important de tester la montée en charge de la volumétrie des données
lorsque plusieurs années de données seront stockées.
Ainsi, pour réduire les risques d’échec de la prise de possession des utili-
sateurs d’une nouvelle solution informatique, une phase d’accompa-
gnement vient compléter la démarche. Cette dernière se traduit par :
 un volet communication ;
 des formations ;
 une entraide ;
 une assistance (téléphonique, etc.) ;
 une maintenance.
La communication permet d’informer les utilisateurs de la mise en
production de l’application. Vous pouvez ainsi organiser une réunion de
présentation du nouvel outil, permettant de prendre connaissance des
principales fonctionnalités proposées.
Les formations, elles, vont permettre une prise en main du nouvel outil.
Pensez à les planifier bien à l’avance et prévoyez un nombre raisonnable
de participants par session (une dizaine est un grand maximum). Un
support de cours viendra accompagner la formation qui se terminera

21. Assistance aux utilisateurs.

 Manager un projet informatique

éventuellement par une enquête de satisfaction sur la prestation. Ce

précieux retour des utilisateurs vous indiquera les axes d’améliorations
concernant autant la formation que la solution logicielle.
Lorsque la livraison de l’application est effectuée, vous devrez en
assurer le suivi afin que cette nouvelle mise en place se passe dans les
meilleures conditions.

Suivi
Le suivi de l’application nouvellement installée démarre dès le retour
de formation des premiers utilisateurs et perdure jusqu’à la cessation
totale d’utilisation de l’application. Ce suivi se traduit par une
assistance aux utilisateurs afin de les accompagner dans leur utilisation
quotidienne et de répondre à leurs questions.
Il s’agit également de prévoir la maintenance non seulement correc-
tive22, mais également évolutive23. En effet, des demandes de mise à
disposition de nouvelles fonctionnalités relatives à l’application de
base pourraient voir le jour. Il est également important de tester, à ce
stade, la montée en charge de la volumétrie des données lorsque
plusieurs années de données seront stockées.
Même si l’application et son suivi sont en place, le projet n’est pas
terminé pour autant Vous allez maintenant devoir dresser son bilan
en vue d’améliorer l’efficacité des projets futurs. © Groupe Eyrolles