# Plan de tests et cahier de recette

| | |
| --- | --- |
| **Projet** | *à compléter* |
| **Version** | *à compléter* |
| **Date** | *à compléter* |
| **Auteur** | *à compléter* |
| **Rédigé par** | MOA / recetteur, avec la MOE |
| **Destinataires** | Métier, MOE, chef de projet, comité de pilotage |
| **Statut** | Brouillon / En relecture / Validé |

---

## 1. Périmètre de la recette

<!-- Ce qui est testé et ce qui ne le sera pas, avec le risque assumé. -->

<!-- Points à couvrir :
     - Fonctions, flux et interfaces couverts
     - Exclusions explicites et justification du risque accepté
     - Versions et lots concernés
-->

*à compléter*

## 2. Niveaux et types de tests

<!-- Qui teste quoi, à quel niveau, pour ne pas tester deux fois la même chose. -->

<!-- Points à couvrir :
     - Tests unitaires et d'intégration : périmètre MOE
     - Recette fonctionnelle : périmètre MOA
     - Tests de bout en bout sur les processus complets
     - Tests de performance et de charge, avec le profil de charge cible
     - Tests de sécurité et de gestion des habilitations
     - Tests de non-régression, et périmètre rejoué à chaque livraison
     - Recette technique : exploitation, reprise sur incident, retour arrière
-->

*à compléter*

## 3. Environnements et jeux de données

<!-- Le point qui fait glisser la plupart des plannings de recette. -->

<!-- Points à couvrir :
     - Environnements utilisés et leur représentativité par rapport à la production
     - Origine des jeux de données et anonymisation des données personnelles
     - Volumétrie utilisée pour les tests de performance
     - Procédure de réinitialisation entre deux campagnes
-->

*à compléter*

## 4. Organisation

<!-- Qui fait quoi, quand, avec quel outillage. -->

<!-- Points à couvrir :
     - Recetteurs désignés par domaine, et charge prévue par personne
     - Calendrier des campagnes et des livraisons
     - Outil de suivi des anomalies et circuit de qualification
-->

*à compléter*

## 5. Cas de test

<!-- Le cœur du cahier de recette. Un cas doit être rejouable par un tiers. -->

<!-- Points à couvrir :
     - Identifiant, exigence ou BUC couvert
     - Préconditions et jeu de données de départ
     - Étapes d'exécution numérotées
     - Résultat attendu, formulé sans ambiguïté
     - Résultat obtenu, statut, date, exécutant
-->

*à compléter*

## 6. Matrice de couverture

<!-- La preuve que le périmètre contractuel est testé. -->

<!-- Points à couvrir :
     - Tableau exigence -> cas de test -> statut
     - Exigences non couvertes et décision associée
-->

*à compléter*

## 7. Gestion des anomalies

<!-- La classification décidée avant la campagne, pas pendant. -->

<!-- Points à couvrir :
     - Grille de sévérité : bloquante, majeure, mineure, cosmétique, avec définition de chacune
     - Circuit : déclaration, qualification, correction, retest, clôture
     - Délais de traitement attendus par niveau de sévérité
-->

*à compléter*

## 8. Critères de sortie

<!-- La règle chiffrée qui autorise la mise en production. -->

<!-- Points à couvrir :
     - Taux d'exécution et taux de réussite minimum exigés
     - Aucune anomalie bloquante ouverte, seuil toléré pour les majeures
     - Anomalies restantes avec contournement documenté et échéance de correction
-->

*à compléter*

---

## Notes de rédaction

**Quand produire ce document**

- Sur tout projet dont la mise en production suit une décision formelle de go / no-go.
- Quand la recette est confiée à des utilisateurs métier qui n'ont pas suivi la conception.
- Sur une migration ou une reprise de données, où la vérification porte sur des volumes et non sur des écrans.
- Quand la réception conditionne un paiement ou le démarrage d'une garantie.

**Erreurs les plus fréquentes**

- Écrire des résultats attendus flous. « Le résultat est correct » n'est pas vérifiable par un tiers, et n'est donc pas un test.
- Découvrir les jeux de données en début de campagne. La préparation des données est la première cause de retard en recette, et elle se prépare en amont.
- Négocier les critères de sortie le jour du comité de mise en production. Posés avant, ils protègent la décision ; posés après, ils la justifient.
- Ne pas tester les cas d'erreur ni les reprises sur incident. La production les testera à votre place, avec des utilisateurs réels.
- Recetter sur des volumes de démonstration. Un traitement validé sur 500 lignes ne dit rien de son comportement sur 5 millions.

**Référentiel de rattachement**

ISO/IEC/IEEE 29119 (test logiciel). La norme sépare la stratégie de test (les niveaux, les critères d'entrée et de sortie, les risques couverts) de la conception des cas de test. Le plan ci-dessous suit cette séparation, en un seul document pour les projets de taille moyenne.

---

Modèle « Plan de tests et cahier de recette » (Recette & qualité), publié par DataALC.
Version en ligne, commentée : https://www.dataalc.com/boite-a-outils/templates/plan-de-tests/

Ce modèle est fourni comme base de travail : adaptez-le à votre contexte, supprimez les rubriques sans objet plutôt que de les laisser vides.