Préparer la recette, la livraison et la clôture

1. Préparer la recette dès le début

La recette examine si le résultat répond aux critères convenus. Elle demande un environnement, des données, des scénarios, des personnes disponibles et une manière de conserver les preuves. La préparer seulement la veille de la livraison crée un risque évitable.

Pour NKILItech, un scénario vérifie qu’un client crée une demande et la retrouve ; un autre vérifie qu’il ne consulte pas le dossier d’un autre client. Les résultats attendus sont écrits avant l’exécution, afin de distinguer une anomalie d’une exigence nouvelle.

La validation technique et l’acceptation métier se complètent. Un système peut réussir des tests unitaires tout en ne répondant pas au besoin réel des utilisateurs.

2. Prononcer une décision explicite

Le procès-verbal de recette peut constater une acceptation, une acceptation avec réserves ou un refus selon les règles convenues. Il identifie la version testée, le périmètre, les résultats, les anomalies et les signataires habilités.

Une réserve doit être décrite avec sa gravité, le contournement éventuel, le responsable et la date de correction attendue. L’équipe ne doit pas confondre une acceptation formelle avec une absence de réponse du client.

Une évolution demandée pendant les essais n’est pas automatiquement un défaut. Comparez-la à l’exigence et au critère initial, puis appliquez le processus de changement si elle élargit l’engagement.

3. Organiser la mise en service

La livraison prépare l’usage réel : version identifiée, environnement, droits, données, sauvegarde, assistance et communication. Une procédure de retour arrière doit préciser quand elle s’applique et comment vérifier le rétablissement du service.

Un lancement progressif avec des utilisateurs pilotes peut réduire certains risques, à condition d’annoncer le périmètre et les modalités de support. Le succès de la copie des fichiers ne suffit pas à démontrer que le service fonctionne pour les utilisateurs.

Le responsable de mise en service dispose d’une liste de contrôles et d’une autorité de décision claire. Les conditions de report doivent être aussi explicites que celles de lancement.

4. Transférer à l’exploitation

Le transfert comprend les guides utiles, les accès autorisés, les contacts de support, les opérations courantes et les procédures de surveillance. Il doit permettre à l’équipe qui reprend le service d’agir sans dépendre de la mémoire d’un seul membre du projet.

La formation se vérifie par une mise en pratique : créer un dossier, traiter une demande ou retrouver une sauvegarde selon le rôle. Le nombre de participants ne prouve pas à lui seul que la prise en main est réussie.

Les engagements de maintenance doivent être distincts de la fin du projet. Qui traite les anomalies restantes ? Qui finance les évolutions ? À partir de quand le support courant prend-il la main ?

5. Clore et suivre les bénéfices

La clôture confirme les livrables acceptés, les engagements restants, le bilan de coût et de délai, ainsi que l’archivage des décisions. Elle organise la libération des ressources et la transmission des responsabilités.

Le retour d’expérience examine des faits et des causes utiles : quelle hypothèse était fausse, quel signal a été ignoré, quelle pratique a aidé l’équipe ? Chaque amélioration retenue doit avoir un responsable et un lieu de réutilisation.

Les bénéfices peuvent être mesurés après la clôture : adoption du portail, temps de recherche d’un dossier ou qualité du suivi. Un responsable de ces mesures est désigné pour que l’objectif initial reste observable après le départ de l’équipe projet.

Exercices corrigés