Recette, documentation et clôture du projet

La recette est la phase où la MOA vérifie que le livrable est conforme à ce qui a été demandé, avant de l'accepter officiellement. Elle s'appuie sur un cahier de recette (la liste des tests à dérouler) et se conclut par un procès-verbal de recette, qui prononce la réception avec ou sans réserves. Viennent ensuite la mise en production, puis la clôture du projet : bilan, retour d'expérience et passage en maintenance. Ce chapitre décrit ces étapes de fin de projet et les documentations à remettre.

Les étapes de la fin d'un projet

1. Les tests internes de la MOE : tests unitaires, d'intégration et de validation, menés par l'équipe sur ses propres environnements (le cycle en V).
2. La recette par la MOA et ses utilisateurs clés, sur un environnement proche de la production.
3. La décision de réception, consignée dans le procès-verbal.
4. La mise en production et l'accompagnement des utilisateurs.
5. La période de garantie ou de vérification en service, pendant laquelle les anomalies découvertes sont corrigées par la MOE.
6. La clôture : bilan, retour d'expérience, archivage, passage en maintenance.

En agile, ces étapes se répètent à petite échelle à chaque sprint : chaque story est vérifiée par le Product Owner selon ses critères d'acceptation, et l'incrément peut être mis en production dès qu'il est prêt. Une recette globale reste souvent utile avant la première mise en service, surtout quand des utilisateurs qui n'ont pas suivi les sprints vont découvrir le produit.

Trois environnements

Une application ne se teste jamais directement là où les utilisateurs travaillent. On distingue au moins trois environnements :

Le cahier de recette

Le cahier de recette liste les cas de test qui vérifient chaque exigence du cahier des charges, ou chaque critère d'acceptation des user stories. Chaque cas de test précise son identifiant, l'exigence vérifiée, les conditions de départ, les étapes, le résultat attendu, puis, lors de l'exécution, le résultat obtenu et le statut.

Le cas R-04 est un test de contrôle d'accès : une recette ne vérifie pas seulement que ce qui doit marcher marche, elle vérifie aussi que ce qui doit être refusé l'est. Le lien entre chaque exigence et ses cas de test s'appelle la traçabilité : à la fin, aucune exigence ne doit rester sans test. Pour le renouvellement du parc, le cahier de recette prend la forme d'une liste de contrôle par poste : session ouverte avec le compte de l'utilisateur, données présentes, logiciels métier lancés, imprimante installée, utilisateur satisfait.

Les anomalies

Chaque écart entre le résultat attendu et le résultat obtenu donne une fiche d'anomalie : identifiant, cas de test, description, étapes pour la reproduire, gravité, auteur, date, statut. Sa gravité décide de la suite :

Une anomalie suit un cycle : ouverte, corrigée par la MOE, vérifiée par la MOA qui rejoue le cas de test, puis close. Après chaque correction, on rejoue aussi les tests des fonctions voisines : c'est le test de non-régression, qui vérifie qu'une correction n'a rien cassé ailleurs.

Le procès-verbal de recette

Le procès-verbal (PV) de recette est le document, signé par la MOA, qui prononce la décision de réception. Trois décisions sont possibles :

• réception sans réserve : le livrable est conforme ;
• réception avec réserves : le livrable est accepté, mais les anomalies listées (non bloquantes) devront être corrigées dans un délai fixé ;
• refus de réception (ou ajournement) : des anomalies bloquantes empêchent l'acceptation ; une nouvelle recette aura lieu après correction.

Le PV a des effets concrets : il marque souvent le transfert de responsabilité de la MOE vers la MOA, le début de la période de garantie et, dans un contrat avec un prestataire, le déclenchement du paiement. Dans les marchés publics et les contrats informatiques, on rencontre deux sigles : la VABF (vérification d'aptitude au bon fonctionnement), qui correspond à la recette, et la VSR (vérification de service régulier), qui vérifie le bon fonctionnement en conditions réelles pendant une durée convenue après la mise en production.

Les documentations d'un projet

Range la documentation technique avec le code (README, dossier docs/ du dépôt) pour qu'elle évolue avec lui. Une documentation qui décrit la version d'il y a six mois est pire que pas de documentation : on la croit. À l'E6, la commission te demande souvent un livrable écrit à côté du code : rapport de test, documentation technique ou utilisateur (l'expression des besoins de l'E6 SLAM).

La mise en production et l'accompagnement

La mise en production se prépare comme une petite opération à part entière :

• un plan de déploiement : les étapes, l'ordre, qui fait quoi, la fenêtre horaire (souvent en dehors des heures de travail) ;
• un plan de retour arrière : comment revenir à la version précédente si la mise en production échoue, et à partir de quand on décide de le faire ;
• une communication aux utilisateurs : ce qui change, quand, à qui s'adresser ;
• un accompagnement : formation, guide, présence renforcée du support les premiers jours.

Dans une organisation qui suit ITIL, la mise en production d'un nouveau service est un changement qui passe par une évaluation et une autorisation (gestion des changements). Les tests d'acceptation, le déploiement et l'accompagnement des utilisateurs forment d'ailleurs une compétence à part entière du bloc 1, « Mettre à disposition des utilisateurs un service informatique » (les compétences du bloc 1).

La clôture du projet

Un projet qui ne se clôt pas traîne : des petites demandes continuent d'arriver, l'équipe n'est jamais libérée et personne ne tire les leçons. La clôture comprend cinq actions.

1. Vérifier que tout est livré et réceptionné : PV signé, réserves levées, documentation remise.
2. Faire le bilan : comparer le prévu et le réel sur le délai, la charge, le coût, le périmètre et la qualité, et vérifier que les objectifs du cahier des charges sont atteints.
3. Mener le retour d'expérience (REX) avec l'équipe et la MOA : ce qui a bien marché, ce qui a moins bien marché, ce qu'on refera ou évitera la prochaine fois. C'est l'équivalent, à l'échelle du projet, de la rétrospective de Scrum.
4. Passer le relais : le service entre en maintenance (corrective et évolutive), assurée par une équipe interne ou par un prestataire (on parle de tierce maintenance applicative, TMA) ; les demandes futures passent par le support et non plus par l'équipe projet.
5. Archiver et libérer : ranger les documents du projet, fermer les accès devenus inutiles, libérer les personnes et le matériel, et remercier l'équipe.

Le bilan du renouvellement du parc

Le coût réel se décompose ainsi : 37,5 jh × 320 € = 12 000 € de main-d'œuvre, 14 400 € de postes, 240 € de recyclage et 380 € de licences du logiciel de transport à réactiver, imprévues : 12 000 + 14 400 + 240 + 380 = 27 020 €.

Le retour d'expérience, mené en 45 minutes avec l'équipe et deux utilisateurs clés, retient :

• à refaire : le pilote sur deux postes, qui a révélé le problème du logiciel de transport avant le déploiement ; le créneau annoncé à chaque service ; la présence au poste le premier matin ;
• à améliorer : l'inventaire initial, qui n'avait pas repéré les licences liées au poste ; le recyclage, réservé trop tard auprès du prestataire, ce qui a coûté un jour et demi en fin de projet ;
• recommandation : ajouter à l'inventaire GLPI un champ « licence liée au matériel » et prévoir le recyclage dès la commande.

Exercices

Exercice 1 sur 4 Écrire des cas de test Réussi À revoir

La story « annuler ma réservation » du club de sport a deux critères d'acceptation : une réservation ne peut plus être annulée moins de deux heures avant le cours ; une place libérée est proposée au premier de la liste d'attente.

Rédige trois cas de test au format du cahier de recette (préconditions, étapes, résultat attendu), dont au moins un cas de refus.

Voir la réponseMasquer la réponse de l'exercice 1

N°	Préconditions	Étapes	Résultat attendu
R-10	Karim inscrit au cours de 18 h ; il est 15 h 30	Karim annule sa réservation	Annulation acceptée ; sa place est libérée
R-11	Karim inscrit au cours de 18 h ; il est 16 h 30	Karim annule sa réservation	Refus, message « Annulation impossible moins de deux heures avant le cours » ; il reste inscrit
R-12	Cours complet ; Inès première sur la liste d'attente ; il est 15 h	Un inscrit annule	La place est proposée à Inès, qui reçoit une notification

On pourrait ajouter le cas limite exactement à deux heures du cours (16 h 00), qu'il faut faire préciser à la MOA : le critère dit « moins de deux heures », donc l'annulation à 16 h 00 pile devrait être acceptée.

Tu avais trouvé ?

Oui, j'avais bonPas encore

Exercice 2 sur 4 Classer les anomalies et décider Réussi À revoir

La recette d'une application de gestion des congés relève quatre anomalies :

1. Le logo est déformé sur la page de connexion.

2. Un salarié peut valider sa propre demande de congés en modifiant l'adresse de la page.

3. Le solde de congés n'est pas mis à jour après une annulation ; la RH peut le corriger à la main.

4. L'export PDF du planning coupe la dernière colonne.

5. Classe chaque anomalie (bloquante, majeure, mineure).

6. Quelle décision de réception proposes-tu ? Pourquoi ?

Voir la réponseMasquer la réponse de l'exercice 2

1. Logo déformé : mineure. Validation de sa propre demande : bloquante (faille de contrôle d'accès, qui contourne la règle de gestion). Solde non mis à jour : majeure (contournement manuel possible). Export coupé : mineure, ou majeure si l'export est utilisé chaque semaine pour l'affichage du planning.
2. Refus de réception (ou ajournement) : l'anomalie 2 est bloquante, c'est un défaut de sécurité qu'on ne met pas en production. Après sa correction et une nouvelle recette (avec un test de non-régression sur la validation), on pourra prononcer une réception avec réserves pour les anomalies 3 et 4, avec un délai de correction, et la 1 dans la foulée.

Tu avais trouvé ?

Oui, j'avais bonPas encore

Exercice 3 sur 4 Faire le bilan d'un projet Réussi À revoir

Une équipe a mené la migration de la messagerie d'une PME. Prévu : 20 jours ouvrés, 18 jh, 9 000 € HT. Réel : 23 jours ouvrés, 21 jh, 9 900 € HT.

1. Calcule les écarts en valeur et en pourcentage.
2. La cause principale du dépassement est la propagation DNS, plus lente que prévu, qui a obligé à garder l'ancien serveur une semaine de plus. Rédige la phrase qui justifie l'écart dans le bilan, et une recommandation pour le retour d'expérience.

Voir la réponseMasquer la réponse de l'exercice 3

1. Délai : +3 jours, soit 3 ÷ 20 = +15 %. Charge : +3 jh, soit 3 ÷ 18 ≈ +16,7 %. Coût : +900 €, soit 900 ÷ 9 000 = +10 %.
2. Par exemple : « Le projet a duré 3 jours de plus que prévu (+15 %) et coûté 900 € de plus (+10 %), parce que la propagation des nouveaux enregistrements DNS a pris plus de temps que prévu et qu'il a fallu maintenir l'ancien serveur et la double réception une semaine supplémentaire. » Recommandation : « Abaisser la durée de vie (TTL) des enregistrements DNS une semaine avant la bascule, et prévoir dans le planning une période de coexistence des deux serveurs. »

Tu avais trouvé ?

Oui, j'avais bonPas encore

Exercice 4 sur 4 Les documentations Réussi À revoir

Pour chaque document, dis à quelle documentation il appartient (technique, exploitation, utilisateur, projet) :

1. La procédure de restauration de la base de Prêt'Matos.
2. Le schéma de la base de données et la justification du choix du framework.
3. La fiche « Comment réserver un ordinateur portable ».
4. Le compte rendu du comité de projet n° 4.
5. La liste des tâches planifiées et des alertes de supervision du serveur.

Voir la réponseMasquer la réponse de l'exercice 4

1. Exploitation. 2. Technique. 3. Utilisateur. 4. Projet. 5. Exploitation.

Tu avais trouvé ?

Oui, j'avais bonPas encore