- Description
- Une loupe qui grossit un timbre-poste ancien posé sur une planche de timbres, tenue entre les doigts.
- Source
- Heptagon · page d’origine
- Licence
- PD Domaine public
Qualité et recette (QUA)
Ce thème traite la qualité du point de vue du pilotage : la livraison est-elle acceptée, sur quels critères, par qui, et quel taux de défauts atteint les utilisateurs ? La qualité technique…
Niveau : 🟢→🔴 · Code : QUA · Matrice : PI
Pourquoi ce thème#
Ce thème traite la qualité du point de vue du pilotage : la livraison est-elle acceptée, sur quels critères, par qui, et quel taux de défauts atteint les utilisateurs ? La qualité technique du code et des tests automatisés relève de la matrice Développement logiciel. Ici, on regarde la recette : une recette tardive, improvisée ou sans critères transforme la mise en production en pari et la relation avec le métier en procès. Un défaut trouvé en production coûte, selon l'ordre de grandeur couramment admis, plusieurs fois à plusieurs dizaines de fois celui trouvé en conception (ordre de grandeur, variable selon le contexte).
Ce que mesure le thème#
- Axe : de la recette de dernière minute à la qualité pilotée par la prévention.
- Indicateur clé : taux de défauts échappés (trouvés après livraison / total) et délai de décision d'acceptation.
- Unité : % de défauts échappés ; jours de recette ; % de critères d'acceptation vérifiés avant livraison.
Les cinq niveaux#
| Niveau | Nom court | Promesse | Indicateur type (ordre de grandeur) |
|---|---|---|---|
| 1 | Recette à la fin | La recette se fait juste avant la livraison, au mieux ; les défauts sont découverts par les utilisateurs. | Échappés : > 30 % |
| 2 | Cahier de recette | Un jeu de cas de recette existe et sert à valider chaque livraison ; les défauts sont tracés. | Échappés : 15 à 30 % |
| 3 | Critères d'avance | Les critères d'acceptation sont connus avant le développement ; la recette est planifiée et partagée entre équipe et métier ; la décision d'accepter est tracée. | Échappés : 8 à 15 % ; 100 % de livraisons avec critères |
| 4 | Défauts mesurés | Les défauts échappés sont analysés par cause ; les recettes s'appuient sur des jeux de référence versionnés ; le trend est suivi. | Échappés : 3 à 8 % ; analyse de cause sur 100 % des majeurs |
| 5 | Prévention | La plupart des défauts sont empêchés en amont ; la recette confirme au lieu de découvrir ; l'utilisateur fait confiance aux chiffres sans les recompter. | Échappés : < 3 % ; critique = zéro |
Jalons par niveau#
| ID | Jalon | Preuve vérifiable |
|---|---|---|
| PI-QUA-1.1 | Une phase de recette est prévue avant la livraison. | Date de recette dans le planning. |
| PI-QUA-1.2 | Les anomalies sont consignées avec un identifiant. | Liste des anomalies des 3 dernières livraisons. |
| PI-QUA-1.3 | Un responsable accepte ou refuse la livraison. | Nom du décideur d'acceptation. |
| PI-QUA-2.1 | Un cahier de recette de scénarios est maintenu. | Version du cahier ; scénarios numérotés. |
| PI-QUA-2.2 | Chaque anomalie a un statut, une gravité et un propriétaire. | Colonne gravité/statut renseignée. |
| PI-QUA-2.3 | Le cahier est rejoué à chaque livraison (au moins sur le cœur). | Compte rendu d'exécution par livraison. |
| PI-QUA-3.1 | Des critères d'acceptation sont écrits avant le développement de chaque exigence. | 10 exigences prises au hasard : critères présents. |
| PI-QUA-3.2 | Les utilisateurs métier participent à la recette (définition et exécution). | Noms et dates de participation. |
| PI-QUA-3.3 | Un seuil de sortie est écrit (par exemple zéro critique, majeurs < 3, plan d'action pour les mineurs). | Seuils documentés ; décision conforme. |
| PI-QUA-3.4 | La décision d'acceptation est tracée avec réserves éventuelles. | Procès-verbal ou compte rendu signé. |
| PI-QUA-3.5 | Les environnements et les jeux de données de recette sont décrits et reproductibles. | Procédure de constitution d'un environnement. |
| PI-QUA-4.1 | Le taux de défauts échappés est calculé par livraison. | Indicateur sur ≥ 6 livraisons. |
| PI-QUA-4.2 | Chaque défaut majeur échappé fait l'objet d'une analyse de cause et d'une action préventive. | Fiches d'analyse ; actions closes. |
| PI-QUA-4.3 | Des jeux de référence (chiffres attendus, cas types) sont versionnés et rejoués. | Dépôt des jeux de référence avec historique. |
| PI-QUA-4.4 | Le délai de recette est mesuré et ne bloque pas la livraison de façon récurrente. | Délais par livraison ; tendance stable ou en baisse. |
| PI-QUA-5.1 | Les causes récurrentes sont supprimées à la racine (outillage, règle, formation). | Baisse du taux sur une cause traitée. |
| PI-QUA-5.2 | Une partie importante de la recette est automatisée et rejouable à la demande. | Part automatisée mesurée (> 60 % des scénarios cœur). |
| PI-QUA-5.3 | Les utilisateurs font confiance aux chiffres livrés : peu de demandes de vérification manuelle. | Nombre de contestations de chiffres en baisse sur 12 mois. |
| PI-QUA-5.4 | Le coût de la qualité (prévention, détection, défaillance) est suivi. | Rapport annuel des trois postes. |
Lecture détaillée par niveau#
Niveau 1. Signes : « on verra en production » ; les utilisateurs deviennent testeurs. Gain : vitesse. Ne garantit pas : la confiance du métier. Difficulté : 1/5. Effort : 1/5.
Niveau 2. Signes : un cahier existe, rejoué sous pression. Gain : un filet minimum. Ne garantit pas que les cas reflètent les besoins métier. Difficulté : 2/5. Effort : 2/5.
Niveau 3. Signes : « on sait ce que veut dire fini » ; la recette est un moment partagé, pas un procès. Gain : moins de discussions de fin de projet, décisions claires. Ne garantit pas l'absence de défauts. Difficulté : 3/5. Effort : 3/5.
Niveau 4. Signes : taux de défauts échappés suivi, analyses de cause, jeux de référence. Gain : les mêmes erreurs ne reviennent pas. Ne garantit pas la qualité perçue (peut ne pas coïncider avec les défauts comptés). Difficulté : 4/5. Effort : 3/5.
Niveau 5. Signes : recette majoritairement automatisée, défauts critiques exceptionnels, coût de la qualité piloté. Gain : confiance et vitesse. Ne garantit pas que les critères soient les bons. Difficulté : 5/5. Effort : 5/5.
Atteinte partielle et notation#
Règle commune : voir README.
- 0,5 : critères écrits mais seulement pour les exigences importantes ; défauts échappés comptés sans analyse de cause.
- 1 : un échantillon de livraisons et de défauts confirme la pratique.
- Un 5 partiel : critères d'avance partout, analyse des causes systématique, recette automatisée à 40 % ; coût de la qualité jamais calculé. Score ≈ 4,5.
Datamart de ventes : la recette métier compare les chiffres d'un échantillon de 20 secteurs au chiffre de référence calculé à la main. Un jeu de référence versionné (20 secteurs × 5 indicateurs, valeurs attendues) rejoué à chaque livraison transforme une demi-journée de vérification en 10 minutes. Voir Recette et validation métier et Tests et fiabilité des chiffres.
Recette-formalité. Symptôme : la recette est « OK » en 30 minutes, les défauts arrivent en production. Cause : testeurs sans scénarios représentatifs, ou pression de délai. Remède : données réalistes, métier acteur, seuil de sortie respecté.
Goodhart : un seuil de « zéro défaut critique » est contourné en reclassant en « majeur ». Faire arbitrer la gravité par une règle écrite et relire un échantillon.
Des critères d'acceptation en forme d'exemples concrets (« donné X, quand Y, alors le total du secteur Z vaut 12 430 ») sont à la fois lisibles par le métier et directement automatisables.
Passer au niveau suivant#
Moyens possibles (facultatifs)
- 1 → 2 : cahier de recette, outil d'anomalies, rejeu minimal.
- 2 → 3 : critères d'acceptation avant développement, présence du métier, seuils de sortie ; voir Scrum en pratique (Definition of Done) et fondamentaux.
- 3 → 4 : indicateur de défauts échappés, analyse des causes, jeux de référence versionnés (voir Azure DevOps / TFS pour les plans de test).
- 4 → 5 : automatisation, prévention à la source, coût de la qualité ; voir Tests (DL).
Peut générer des cas de test et des jeux de données, comparer des écarts entre versions de rapports et reformuler des critères ; ne juge pas si un chiffre est « bon » pour le métier, et des tests générés sans relecture donnent une couverture factice.
Voir aussi#
- Thèmes voisins : 04 Périmètre et exigences · 09 Livraison · 10 Amélioration continue · 07 Parties prenantes.
- Autres matrices : Tests (DL) · Qualité du code (DL) · Qualité des données (data) · Recette et validation métier (data).
- Pratique : Scrum en pratique · Pièges et bonnes pratiques · Glossaire.
✻ Rédigé par Claude Sonnet 5.5
