Le recettage informatique : valider une installation, preuves à l’appui

Qu’est-ce qu’un recettage ?

Le recettage (ou recette) est la phase de vérification formelle qui permet de s’assurer qu’une installation, une configuration ou une application fonctionne conformément à ce qui était attendu, avant de la déclarer opérationnelle, de la mettre en production ou de la livrer.

Il ne s’agit pas de « constater que ça a l’air de marcher », mais de démontrer, test par test et preuves à l’appui, que chaque exigence du cahier des charges est satisfaite. Le recettage se conclut par une décision : on accepte l’installation (avec ou sans réserves) ou on la refuse.

Vocabulaire essentiel

Terme	Signification
Cahier des charges	Document qui exprime le besoin et les exigences : c’est la référence à partir de laquelle on définit ce qui doit être vérifié.
Cahier de recette	Ensemble organisé des tests à réaliser, avec pour chacun la procédure et le résultat attendu.
Cas de test / fiche de test	Description d’un test précis : objectif, prérequis, actions, résultat attendu, résultat obtenu, preuve, statut.
Preuve	Élément qui atteste du résultat obtenu : capture d’écran explicitée, sortie de commande, extrait de journal, fichier exporté…
Anomalie	Écart constaté entre le résultat attendu et le résultat obtenu. Elle est décrite, qualifiée (bloquante, majeure, mineure) et suivie jusqu’à sa correction.
Non-régression	Vérification qu’une correction ou une modification n’a pas dégradé ce qui fonctionnait déjà.
Réserve	Anomalie non bloquante acceptée provisoirement, avec engagement de correction dans un délai fixé.
PV de recette	Procès-verbal qui acte officiellement la décision : recette prononcée sans réserve, avec réserves, ou refusée.

Pourquoi faire un recettage ?

Le recettage est souvent perçu comme une formalité. C’est pourtant lui qui transforme une installation « qui semble marcher » en une installation validée, documentée et défendable.

Intérêt	Explication
Prouver plutôt qu’affirmer	Chaque exigence est vérifiée et accompagnée d’une preuve. On ne se contente plus d’un « c’est fait ».
Détecter les défauts tôt	Une erreur trouvée avant la mise en production coûte beaucoup moins cher qu’un incident chez les utilisateurs.
Assurer la traçabilité	On sait ce qui a été testé, quand, par qui, dans quelle version et avec quel résultat.
Sécuriser la relation client	Le PV de recette formalise la livraison : il protège le prestataire comme le client en cas de litige.
Faciliter la maintenance	Le cahier de recette sert de référence pour les tests de non-régression lors des évolutions futures.
Valoriser les compétences	En BTS SIO, un recettage bien mené est une excellente preuve de compétences pour le portfolio et les épreuves professionnelles.

Les différents types de tests

Un recettage complet combine plusieurs familles de tests. Toutes ne sont pas nécessaires à chaque fois : on les choisit en fonction de ce qui est livré.

Type de test	Question posée	Exemples
Fonctionnel	Le service rend-il le service attendu ?	Un poste obtient une adresse DHCP ; un utilisateur se connecte à l’application.
Configuration	Les paramètres appliqués sont-ils ceux prévus ?	Plage DHCP, options DNS, version installée, nom d’hôte, fuseau horaire.
Sécurité	L’installation est-elle correctement protégée ?	Comptes par défaut désactivés, ports ouverts limités, droits minimaux, journalisation active.
Droits et accès	Chacun accède-t-il uniquement à ce qui le concerne ?	Un utilisateur standard ne peut pas modifier un partage réservé aux administrateurs.
Non-régression	Ce qui marchait marche-t-il toujours ?	Après une mise à jour, les services précédemment validés sont re-testés.
Robustesse / reprise	Le système résiste-t-il à un incident ?	Redémarrage d’un serveur, bascule HA, restauration d’une sauvegarde.
Performance	Les temps de réponse sont-ils acceptables ?	Temps d’ouverture d’une page, débit d’un transfert, charge processeur.

Mettre en place un recettage, étape par étape

Étape 1 : partir du besoin

Relire le cahier des charges (ou le sujet du TP) et lister les exigences vérifiables. Une exigence floue (« le réseau doit bien marcher ») doit être reformulée en critère mesurable (« un poste du VLAN 10 joint le serveur web en moins de 2 secondes »).

Étape 2 : rédiger le cahier de recette

Pour chaque exigence, rédiger une ou plusieurs fiches de test : objectif, prérequis, procédure détaillée, résultat attendu écrit avant le test. Cette rédaction en amont évite d’adapter le résultat attendu à ce que l’on observe.

Étape 3 : préparer l’environnement

• Identifier les machines, les comptes de test et les outils nécessaires.
• Noter les versions installées et l’état initial (instantané de VM conseillé).
• Utiliser des comptes de test dédiés plutôt que des comptes administrateurs réels.

Étape 4 : exécuter les tests et collecter les preuves

Dérouler les tests dans l’ordre prévu, sans improviser. Pour chacun, renseigner le résultat obtenu et produire la preuve correspondante (capture explicitée, sortie de commande). Si un test échoue, on le note tel quel : une anomalie documentée a plus de valeur qu’un test « arrangé ».

Étape 5 : analyser et qualifier les anomalies

Gravité	Définition	Conséquence
Bloquante	Empêche l’utilisation du service ou crée un risque de sécurité important.	Recette refusée tant que non corrigée.
Majeure	Dégrade fortement le service, mais un contournement existe.	Correction avant mise en production, ou réserve encadrée.
Mineure	Gêne limitée, sans impact sur l’usage principal.	Peut être acceptée en réserve.

Étape 6 : corriger et re-tester

Après chaque correction, rejouer le test concerné puis les tests de non-régression liés. Conserver la trace des deux passages (avant et après correction).

Étape 7 : conclure par un procès-verbal

Le PV de recette synthétise les résultats et formalise la décision. Il est daté et signé par le testeur et par la personne qui valide (client, responsable, enseignant).

Les captures d’écran explicitées

La capture d’écran est la preuve que le test a été réalisé et qu’il a donné le résultat annoncé. Mais une capture seule ne démontre rien si le lecteur ne sait pas ce qu’il doit y voir. Elle doit donc toujours être explicitée.

Les quatre éléments d’une capture explicitée

Élément	Contenu attendu
Contexte	Sur quelle machine, avec quel compte, dans quel outil. Le nom d’hôte, l’invite de commande ou la barre de titre doivent être visibles.
Action	La commande saisie, le menu ouvert ou l’opération effectuée.
Zone à observer	Le passage précis qui prouve le résultat, mis en évidence (encadré, flèche, surlignage).
Interprétation	Une ou deux phrases qui expliquent pourquoi ce résultat est conforme (ou non) au résultat attendu.

Bonnes pratiques

• Recadrer la capture sur la zone utile, tout en gardant le contexte (nom de machine, utilisateur).
• Numéroter chaque capture et y faire référence dans la fiche de test (« voir capture 4 »).
• Privilégier la sortie texte d’une commande lorsqu’elle est plus lisible qu’une image.
• Une capture = une preuve. Éviter les captures d’écran entier sans mise en évidence.

Exemple

Test : vérifier que le serveur DNS résout le nom du serveur de fichiers depuis un poste client.

PS C:\Users\test.user> nslookup srv-fichiers.entreprise.local
Serveur :   srv-dc01.entreprise.local
Address: 192.168.10.10

Nom :    srv-fichiers.entreprise.local
Address: 192.168.10.20

Modèles à utiliser et à adapter

Les modèles ci-dessous sont proposés à titre indicatif. Ils peuvent être copiés autant de fois que nécessaire et adaptés : ajout de rubriques, regroupement de tests, simplification pour un petit TP ou enrichissement pour un projet complet. Ils figurent aussi, prêts à imprimer, dans le livret PDF.

Modèle 1 : identification du recettage

Rubrique	À renseigner
Projet / installation	Ex. : mise en place du service DHCP du site principal
Référence du besoin	Cahier des charges, sujet de TP, ticket…
Environnement	Machines, systèmes, versions, réseau de test
Testeur(s)
Valideur	Client, responsable, enseignant
Date(s) de la recette
Version du document

Modèle 2 : fiche de test

Fiche de test n° ___
Exigence couverte	Référence de l’exigence du cahier des charges
Objectif du test	Ce que l’on cherche à démontrer
Type de test	Fonctionnel / configuration / sécurité / droits / non-régression / robustesse
Prérequis	État de départ, comptes, machines nécessaires
Procédure	1. … 2. … 3. …
Résultat attendu	À rédiger AVANT l’exécution
Résultat obtenu
Preuve(s)	Capture(s) n° … / sortie de commande / journal
Statut	☐ Conforme ☐ Non conforme ☐ Conforme avec réserve
Anomalie / commentaire	Description, gravité (bloquante / majeure / mineure)
Re-test après correction	Date : …… Résultat : ☐ Conforme ☐ Non conforme

Modèle 3 : capture explicitée

Capture n° ___ (liée à la fiche de test n° ___)
Contexte	Machine, compte utilisé, outil
Action réalisée	Commande, menu, opération
Capture	Insérer la capture ici : recadrée, zone utile encadrée
Zone à observer	Ce que le lecteur doit regarder
Interprétation	Pourquoi le résultat est conforme ou non
Données masquées	☐ Aucune donnée sensible ☐ Oui, masquées : ……

Modèle 4 : tableau de synthèse

N°	Test	Statut	Anomalie / réserve	Re-test
1
2
3
…

Modèle 5 : procès-verbal de recette

Procès-verbal de recette
Projet / installation
Bilan des tests	…… tests réalisés : …… conformes, …… non conformes, …… avec réserve
Décision	☐ Recette prononcée sans réserve ☐ Recette prononcée avec réserves ☐ Recette refusée
Réserves éventuelles	Description et délai de levée
Testeur	Nom, date, signature
Valideur	Nom, date, signature